search for: xdp_frames

From: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp> Date: Thu, 31 Jan 2019 20:40:30 +0900 > Previously virtnet_xdp_xmit() did not account for device tx counters, > which caused confusions. > To be consistent with SKBs, account them on freeing xdp_frames. > > Reported-by: David Ahern <dsahern at gmail.com> > Signed-off-by: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp> Applied, thank you.

...:25:17 -0500 >> >>> On Thu, Jan 31, 2019 at 08:40:30PM +0900, Toshiaki Makita wrote: >>>> Previously virtnet_xdp_xmit() did not account for device tx counters, >>>> which caused confusions. >>>> To be consistent with SKBs, account them on freeing xdp_frames. >>>> >>>> Reported-by: David Ahern <dsahern at gmail.com> >>>> Signed-off-by: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp> >>> >>> Well we count them on receive so I guess it makes sense for consistency >>> >>...

On Sat, 2 Feb 2019 14:27:26 -0700 David Ahern <dsahern at gmail.com> wrote: > On 1/31/19 1:15 PM, Jesper Dangaard Brouer wrote: > >> > >> David, Jesper, care to chime in where we ended up in that last thread > >> discussion this? > > > > IHMO packets RX and TX on a device need to be accounted, in standard > > counters, regardless of XDP.

On Wed, 6 Feb 2019 00:06:33 +0000 Saeed Mahameed <saeedm at mellanox.com> wrote: > On Mon, 2019-02-04 at 19:13 -0800, David Ahern wrote: [...] > > > > mlx5 needs some work. As I recall it still has the bug/panic > > removing xdp programs - at least I don't recall seeing a patch for > > it. > > Only when xdp_redirect to mlx5, and removing the program

On Wed, 6 Feb 2019 00:06:33 +0000 Saeed Mahameed <saeedm at mellanox.com> wrote: > 2) Driver should keep track of XDP decisions statistics, report them in > ethtool and in the new API suggested by David. track even (XDP_PASS) ? > > Maybe instead of having all drivers track the statistics on their own, > we should move the responsibility to upper layer. > > Idea: since

On Sat, 9 Feb 2019 00:18:31 +0000, Saeed Mahameed wrote: > 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 > >

On Wed, 6 Feb 2019 00:06:33 +0000 Saeed Mahameed <saeedm at mellanox.com> wrote: > 3) Unrelated, In non XDP case, if skb allocation fails or driver fails > to pass the skb up to the stack for somereason, should the driver > increase rx packets ? IMHO the answer should be yes if we want to have > similar behavior between XDP and non XDP cases. I don't think "skb

David Ahern <dsahern at gmail.com> writes: > On 2/4/19 3:53 AM, Jesper Dangaard Brouer wrote: >> On Sat, 2 Feb 2019 14:27:26 -0700 >> David Ahern <dsahern at gmail.com> wrote: >> >>> On 1/31/19 1:15 PM, Jesper Dangaard Brouer wrote: >>>>> >>>>> David, Jesper, care to chime in where we ended up in that last thread

On Tue, Mar 28, 2023 at 8:04?PM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > At present, we have two similar logic to perform the XDP prog. > > Therefore, this PATCH separates the code of executing XDP, which is > conducive to later maintenance. > > Signed-off-by: Xuan Zhuo <xuanzhuo at linux.alibaba.com> > --- > drivers/net/virtio_net.c | 142

If the queue of xdp xmit is not an independent queue, then when the xdp xmit used all the desc, the xmit from the __dev_queue_xmit() may encounter the following error. net ens4: Unexpected TXQ (0) queue failure: -28 This patch adds a check whether sq is full in XDP Xmit. Thanks. v1: 1. rename to check_sq_full_and_disable 2. reorder some funcs to avoid declaration Xuan Zhuo (3):

On Tue, 4 Apr 2023 13:04:02 +0800, Jason Wang <jasowang at redhat.com> wrote: > On Mon, Apr 3, 2023 at 12:17?PM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > > > On Mon, 3 Apr 2023 10:43:03 +0800, Jason Wang <jasowang at redhat.com> wrote: > > > On Tue, Mar 28, 2023 at 8:04?PM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > >

On Tue, Apr 4, 2023 at 2:22?PM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > On Tue, 4 Apr 2023 13:04:02 +0800, Jason Wang <jasowang at redhat.com> wrote: > > On Mon, Apr 3, 2023 at 12:17?PM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > > > > > On Mon, 3 Apr 2023 10:43:03 +0800, Jason Wang <jasowang at redhat.com> wrote: > >

On Tue, Apr 4, 2023 at 2:55?PM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > On Tue, 4 Apr 2023 14:35:05 +0800, Jason Wang <jasowang at redhat.com> wrote: > > On Tue, Apr 4, 2023 at 2:22?PM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > > > > > On Tue, 4 Apr 2023 13:04:02 +0800, Jason Wang <jasowang at redhat.com> wrote: > >

Commit 5b8f3c8d30a6 ("virtio_net: Add XDP related stats") tries to count TX XDP stats in virtnet_receive(). This will cause several issues: - virtnet_xdp_sq() was called without checking whether or not XDP is set. This may cause out of bound access when there's no enough txq for XDP. - Stats were updated even if there's no XDP/XDP_TX. Fixing this by reusing

Commit 5b8f3c8d30a6 ("virtio_net: Add XDP related stats") tries to count TX XDP stats in virtnet_receive(). This will cause several issues: - virtnet_xdp_sq() was called without checking whether or not XDP is set. This may cause out of bound access when there's no enough txq for XDP. - Stats were updated even if there's no XDP/XDP_TX. Fixing this by reusing

On 2020/5/6 ??4:21, Jesper Dangaard Brouer wrote: > On Wed, 6 May 2020 14:16:32 +0800 > Jason Wang <jasowang at redhat.com> wrote: > >> We tried to reserve space for vnet header before >> xdp.data_hard_start. But this is useless since the packet could be >> modified by XDP which may invalidate the information stored in the >> header and > IMHO above

On 2020/5/6 ??4:21, Jesper Dangaard Brouer wrote: > On Wed, 6 May 2020 14:16:32 +0800 > Jason Wang <jasowang at redhat.com> wrote: > >> We tried to reserve space for vnet header before >> xdp.data_hard_start. But this is useless since the packet could be >> modified by XDP which may invalidate the information stored in the >> header and > IMHO above

On Wed, 6 May 2020 14:16:32 +0800 Jason Wang <jasowang at redhat.com> wrote: > We tried to reserve space for vnet header before > xdp.data_hard_start. But this is useless since the packet could be > modified by XDP which may invalidate the information stored in the > header and IMHO above statements are wrong. XDP cannot access memory before xdp.data_hard_start. Thus, it is

On Wed, May 06, 2020 at 04:34:36PM +0800, Jason Wang wrote: > > On 2020/5/6 ??4:21, Jesper Dangaard Brouer wrote: > > On Wed, 6 May 2020 14:16:32 +0800 > > Jason Wang <jasowang at redhat.com> wrote: > > > > > We tried to reserve space for vnet header before > > > xdp.data_hard_start. But this is useless since the packet could be > > >

We tried to reserve space for vnet header before xdp.data_hard_start. But this is useless since the packet could be modified by XDP which may invalidate the information stored in the header and there's no way for XDP to know the existence of the vnet header currently. So let's just not reserve space for vnet header in this case. Cc: Jesper Dangaard Brouer <brouer at redhat.com>