From: "Toke Høiland-Jørgensen" <toke@redhat•com>
To: Saeed Mahameed <saeedm@mellanox•com>,
"brouer\@redhat.com" <brouer@redhat•com>
Cc: "hawk\@kernel.org" <hawk@kernel•org>,
"virtualization\@lists.linux-foundation.org"
<virtualization@lists•linux-foundation.org>,
"borkmann\@iogearbox.net" <borkmann@iogearbox•net>,
Tariq Toukan <tariqt@mellanox•com>,
"john.fastabend\@gmail.com" <john.fastabend@gmail•com>,
"mst\@redhat.com" <mst@redhat•com>,
"jakub.kicinski\@netronome.com" <jakub.kicinski@netronome•com>,
"dsahern\@gmail.com" <dsahern@gmail•com>,
"netdev\@vger.kernel.org" <netdev@vger•kernel.org>,
"jasowang\@redhat.com" <jasowang@redhat•com>,
"davem\@davemloft.net" <davem@davemloft•net>,
"makita.toshiaki\@lab.ntt.co.jp" <makita.toshiaki@lab•ntt.co.jp>
Subject: Re: Resource management for ndo_xdp_xmit (Was: [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames)
Date: Sat, 09 Feb 2019 17:56:10 +0100 [thread overview]
Message-ID: <87d0o0q4t1.fsf@toke.dk> (raw)
In-Reply-To: <b4eb9dd1c7aaa3215ade8d3d17f397588a519ca3.camel@mellanox.com>
Saeed Mahameed <saeedm@mellanox•com> writes:
> On Fri, 2019-02-08 at 15:17 -0800, Saeed Mahameed wrote:
>> On Thu, 2019-02-07 at 19:08 +0000, Saeed Mahameed wrote:
>> >
>> > So
>> > 1) on dev_map_update_elem() we will call
>> > dev->dev->ndo_bpf() to notify the device on the intention to
>> > start/stop
>> > redirect, and wait for it to create/destroy the HW resources
>> > before/after actually updating the map
>> >
>>
>> silly me, dev_map_update_elem must be atomic, we can't hook driver
>> resource allocation to it, it must come as a separate request
>> (syscall)
>> from user space to request to create XDP redirect resources.
>>
>
> Well, it is possible to render dev_map_update_elem non-atomic and fail
> BPF programs who try to update it in the verifier
> check_map_func_compatibility.
>
> if you know of any case where devmap needs to be updated from the BPF
> program please let me know.
Well, maybe? My plan for dealing with the non-map redirect variant is
essentially to have a hidden map that does just-in-time insertion of
ifindexes if they are not already there; and rework XDP_REDIRECT to use
that.
However, this would essentially be an insert from eBPF; but I guess
maybe it could be deferred until the RX-side driver exits its NAPI loop
(as we're buffering frames in the map anyway)?
-Toke
next prev parent reply other threads:[~2019-02-09 16:56 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-31 11:40 [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames Toshiaki Makita
2019-01-31 15:25 ` Michael S. Tsirkin
2019-01-31 17:45 ` David Miller
2019-01-31 20:15 ` Jesper Dangaard Brouer
2019-02-01 1:53 ` Toshiaki Makita
2019-02-02 21:27 ` David Ahern
2019-02-04 11:53 ` Jesper Dangaard Brouer
2019-02-05 3:13 ` David Ahern
2019-02-06 0:06 ` Saeed Mahameed
2019-02-06 13:48 ` Jesper Dangaard Brouer
2019-02-06 15:52 ` Jakub Kicinski
2019-02-07 7:48 ` Resource management for ndo_xdp_xmit (Was: [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames) Jesper Dangaard Brouer
2019-02-07 19:08 ` Saeed Mahameed
2019-02-08 16:55 ` Toke Høiland-Jørgensen
2019-02-08 22:49 ` Saeed Mahameed
2019-02-08 23:17 ` Saeed Mahameed
2019-02-09 0:18 ` Saeed Mahameed
2019-02-09 2:05 ` Jakub Kicinski
2019-02-09 16:56 ` Toke Høiland-Jørgensen
2019-02-09 16:56 ` Toke Høiland-Jørgensen [this message]
2019-02-08 16:02 ` [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames Jesper Dangaard Brouer
2019-04-18 14:24 ` Stats for XDP actions (was: Re: [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames) Toke Høiland-Jørgensen
2019-04-21 0:16 ` Stats for XDP actions David Ahern
2019-06-20 20:42 ` Toke Høiland-Jørgensen
2019-06-21 0:42 ` David Ahern
2019-06-21 13:57 ` Toke Høiland-Jørgensen
2019-02-04 4:18 ` [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d0o0q4t1.fsf@toke.dk \
--to=toke@redhat$(echo .)com \
--cc=borkmann@iogearbox$(echo .)net \
--cc=brouer@redhat$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=dsahern@gmail$(echo .)com \
--cc=hawk@kernel$(echo .)org \
--cc=jakub.kicinski@netronome$(echo .)com \
--cc=jasowang@redhat$(echo .)com \
--cc=john.fastabend@gmail$(echo .)com \
--cc=makita.toshiaki@lab$(echo .)ntt.co.jp \
--cc=mst@redhat$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=saeedm@mellanox$(echo .)com \
--cc=tariqt@mellanox$(echo .)com \
--cc=virtualization@lists$(echo .)linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox