search for: num_bufs

On Mon, May 21, 2018 at 04:35:05PM +0800, Jason Wang wrote: > If we successfully linearize the packets, num_buf were set to zero > which was wrong since we now have only 1 buffer to be used for e.g in > the error path of receive_mergeable(). Zero num_buf will lead the code > try to pop the buffers of next packet and drop it. Fixing this by set > num_buf to 1 if we successfully

Hi, On Tue, 2023-03-28 at 20:04 +0800, Xuan Zhuo wrote: > The purpose of this patch is to simplify the receive_mergeable(). > Separate all the logic of XDP into a function. > > Signed-off-by: Xuan Zhuo <xuanzhuo at linux.alibaba.com> > --- > drivers/net/virtio_net.c | 128 +++++++++++++++++++++++---------------- > 1 file changed, 76 insertions(+), 52 deletions(-) >

This patch introduce a new function that frees the rest mergeable buf. The subsequent patch will reuse this function. Signed-off-by: Xuan Zhuo <xuanzhuo at linux.alibaba.com> --- drivers/net/virtio_net.c | 36 ++++++++++++++++++++++++------------ 1 file changed, 24 insertions(+), 12 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index

The purpose of this patch is to simplify the receive_mergeable(). Separate all the logic of XDP into a function. Signed-off-by: Xuan Zhuo <xuanzhuo at linux.alibaba.com> --- drivers/net/virtio_net.c | 128 +++++++++++++++++++++++---------------- 1 file changed, 76 insertions(+), 52 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index

Eric Dumazet noticed that if we encounter an error when processing a mergeable buffer, we don't dequeue all of the buffers from this packet, the result is almost sure to be loss of networking. Fix this issue. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Michael Dalton <mwdalton at google.com> Acked-by: Michael Dalton <mwdalton at google.com> Cc: Eric Dumazet

Eric Dumazet noticed that if we encounter an error when processing a mergeable buffer, we don't dequeue all of the buffers from this packet, the result is almost sure to be loss of networking. Fix this issue. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Michael Dalton <mwdalton at google.com> Acked-by: Michael Dalton <mwdalton at google.com> Cc: Eric Dumazet

If we successfully linearize the packets, num_buf were set to zero which was wrong since we now have only 1 buffer to be used for e.g in the error path of receive_mergeable(). Zero num_buf will lead the code try to pop the buffers of next packet and drop it. Fixing this by set num_buf to 1 if we successfully linearize the packet. Fixes: 4941d472bf95 ("virtio-net: do not reset during XDP

Eric Dumazet noticed that if we encounter an error when processing a mergeable buffer, we don't dequeue all of the buffers from this packet, the result is almost sure to be loss of networking. Jason Wang noticed that we also leak a page and that we don't decrement the rq buf count, so we won't repost buffers (a resource leak). Fix both issues. Cc: Rusty Russell <rusty at

Eric Dumazet noticed that if we encounter an error when processing a mergeable buffer, we don't dequeue all of the buffers from this packet, the result is almost sure to be loss of networking. Jason Wang noticed that we also leak a page and that we don't decrement the rq buf count, so we won't repost buffers (a resource leak). Fix both issues. Cc: Rusty Russell <rusty at

----- ???? ----- > On Wed, Nov 20, 2013 at 05:07:25PM +0800, Jason Wang wrote: > > When mergeable buffer were used, we only put the first page buf leave the > > rest > > of buffers in the virt queue. This will cause the driver could not get the > > correct head buffer any more. Fix this by dropping the rest of buffers for > > this > > packet. > > >

----- ???? ----- > On Wed, Nov 20, 2013 at 05:07:25PM +0800, Jason Wang wrote: > > When mergeable buffer were used, we only put the first page buf leave the > > rest > > of buffers in the virt queue. This will cause the driver could not get the > > correct head buffer any more. Fix this by dropping the rest of buffers for > > this > > packet. > > >

Separating the logic of preparation for xdp from receive_mergeable. The purpose of this is to simplify the logic of execution of XDP. The main logic here is that when headroom is insufficient, we need to allocate a new page and calculate offset. It should be noted that if there is new page, the variable page will refer to the new page. Signed-off-by: Xuan Zhuo <xuanzhuo at

Due to historical reasons, the implementation of XDP in virtio-net is relatively chaotic. For example, the processing of XDP actions has two copies of similar code. Such as page, xdp_page processing, etc. The purpose of this patch set is to refactor these code. Reduce the difficulty of subsequent maintenance. Subsequent developers will not introduce new bugs because of some complex logical

? 2023/3/28 20:04, Xuan Zhuo ??: > Separating the logic of preparation for xdp from receive_mergeable. > > The purpose of this is to simplify the logic of execution of XDP. > > The main logic here is that when headroom is insufficient, we need to > allocate a new page and calculate offset. It should be noted that if > there is new page, the variable page will refer to the new

Due to historical reasons, the implementation of XDP in virtio-net is relatively chaotic. For example, the processing of XDP actions has two copies of similar code. Such as page, xdp_page processing, etc. The purpose of this patch set is to refactor these code. Reduce the difficulty of subsequent maintenance. Subsequent developers will not introduce new bugs because of some complex logical

Eric Dumazet noticed that if we encounter an error when processing a mergeable buffer, we don't dequeue all of the buffers from this packet, the result is almost sure to be loss of networking. Jason Wang noticed that we also leak a page and that we don't decrement the rq buf count, so we won't repost buffers (a resource leak). Fix both issues, and also make the logic a bit more

Eric Dumazet noticed that if we encounter an error when processing a mergeable buffer, we don't dequeue all of the buffers from this packet, the result is almost sure to be loss of networking. Jason Wang noticed that we also leak a page and that we don't decrement the rq buf count, so we won't repost buffers (a resource leak). Fix both issues, and also make the logic a bit more

We don't put page during linearizing, the would cause leaking when xmit through XDP_TX or the packet exceeds PAGE_SIZE. Fix them by put page accordingly. Also decrease the number of buffers during linearizing to make sure caller can free buffers correctly when packet exceeds PAGE_SIZE. With this patch, we won't get OOM after linearize huge number of packets. Cc: John Fastabend

When mergeable buffer were used, we only put the first page buf leave the rest of buffers in the virt queue. This will cause the driver could not get the correct head buffer any more. Fix this by dropping the rest of buffers for this packet. The bug was introduced by commit 9ab86bbcf8be755256f0a5e994e0b38af6b4d399 (virtio_net: Defer skb allocation in receive path). Cc: Rusty Russell <rusty at

When mergeable buffer were used, we only put the first page buf leave the rest of buffers in the virt queue. This will cause the driver could not get the correct head buffer any more. Fix this by dropping the rest of buffers for this packet. The bug was introduced by commit 9ab86bbcf8be755256f0a5e994e0b38af6b4d399 (virtio_net: Defer skb allocation in receive path). Cc: Rusty Russell <rusty at