All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: mst@redhat.com, virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	john.fastabend@gmail.com,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>
Subject: Re: [PATCH net-next 0/2] virtio-net: re enable XDP_REDIRECT for mergeable buffer
Date: Thu, 1 Mar 2018 21:15:36 +0800	[thread overview]
Message-ID: <872bf3ea-7631-4e5f-9a6a-d632213cd15c@redhat.com> (raw)
In-Reply-To: <20180301113531.7b25e2df@redhat.com>



On 2018年03月01日 18:35, Jesper Dangaard Brouer wrote:
> On Thu, 1 Mar 2018 17:23:37 +0800
> Jason Wang <jasowang@redhat.com> wrote:
>
>> On 2018年03月01日 17:10, Jesper Dangaard Brouer wrote:
>>> On Thu,  1 Mar 2018 11:19:03 +0800
>>> Jason Wang <jasowang@redhat.com> wrote:
>>>   
>>>> This series tries to re-enable XDP_REDIRECT for mergeable buffer which
>>>> was removed since commit 7324f5399b06 ("virtio_net: disable
>>>> XDP_REDIRECT in receive_mergeable() case"). Main concerns are:
>>>>
>>>> - not enough tailroom was reserved which breaks cpumap
>>> To address this at a more fundamental level, I would suggest that we/you
>>> instead extend XDP to know it's buffers "frame" size/end.  (The
>>> assumption use to be, xdp_buff->data_hard_start + PAGE_SIZE, but
>>> ixgbe+virtio_net broke that assumption).
>>>
>>> It should actually be fairly easy to implement:
>>>    * Simply extend xdp_buff with a "data_hard_end" pointer.
>> Right, and then cpumap can warn and drop packets with insufficient
>> tailroom.
>>
>> But it should be a patch on top of this I think.
> Hmmm, not really.  If we/you instead fix the issue of XDP doesn't know
> the end/size of the frame, then we don't need this mixed XDP
> generic/native code path mixing.

I know this but I'm still a little bit confused. According to the commit 
log of 7324f5399b06 ("virtio_net: disable XDP_REDIRECT in 
receive_mergeable() case"), you said:

"""
     The longer explaination is that receive_mergeable() tries to
     work-around and satisfy these XDP requiresments e.g. by having a
     function xdp_linearize_page() that allocates and memcpy RX buffers
     around (in case packet is scattered across multiple rx buffers).  This
     does currently satisfy XDP_PASS, XDP_DROP and XDP_TX (but only because
     we have not implemented bpf_xdp_adjust_tail yet).
"""

So I consider the tailroom is a must for the (future) tail adjustment.

>
> You could re-enable native redirect, and push the responsibility to
> cpumap for detecting this too-small frame "missing tailroom" (and avoid
> crashing...). (If we really want to support this, cpumap could fallback
> to dev_alloc_skb, and handle it gracefully).
>

Right but it will be slower than build_skb().

Thanks

  reply	other threads:[~2018-03-01 13:15 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-01  3:19 [PATCH net-next 0/2] virtio-net: re enable XDP_REDIRECT for mergeable buffer Jason Wang
2018-03-01  3:19 ` Jason Wang
2018-03-01  3:19 ` [PATCH net-next 1/2] " Jason Wang
2018-03-01  3:19 ` Jason Wang
2018-03-01  8:41   ` Jesper Dangaard Brouer
2018-03-01  8:41   ` Jesper Dangaard Brouer
2018-03-01  9:11     ` Jason Wang
2018-03-01  9:11       ` Jason Wang
2018-03-01 13:36   ` Michael S. Tsirkin
2018-03-01 13:36     ` Michael S. Tsirkin
2018-03-02  4:20     ` Jason Wang
2018-03-02  4:20       ` Jason Wang
2018-03-01  3:19 ` [PATCH net-next 2/2] virtio-net: simplify XDP handling in small buffer Jason Wang
2018-03-01  8:02   ` Jesper Dangaard Brouer
2018-03-01  8:02   ` Jesper Dangaard Brouer
2018-03-01  8:49     ` Jason Wang
2018-03-01  9:15       ` Jesper Dangaard Brouer
2018-03-01  9:15         ` Jesper Dangaard Brouer
2018-03-01  9:24         ` Jason Wang
2018-03-01  9:24         ` Jason Wang
2018-03-01  8:49     ` Jason Wang
2018-03-01  3:19 ` Jason Wang
2018-03-01  9:10 ` [PATCH net-next 0/2] virtio-net: re enable XDP_REDIRECT for mergeable buffer Jesper Dangaard Brouer
2018-03-01  9:10   ` Jesper Dangaard Brouer
2018-03-01  9:23   ` Jason Wang
2018-03-01  9:23   ` Jason Wang
2018-03-01 10:35     ` Jesper Dangaard Brouer
2018-03-01 10:35       ` Jesper Dangaard Brouer
2018-03-01 13:15       ` Jason Wang [this message]
2018-03-01 14:16         ` Jesper Dangaard Brouer
2018-03-01 14:16           ` Jesper Dangaard Brouer
2018-03-02  4:17           ` Jason Wang
2018-03-02  4:17             ` Jason Wang
2018-03-01 13:15       ` Jason Wang
2018-03-01 13:40       ` Michael S. Tsirkin
2018-03-01 13:40         ` Michael S. Tsirkin

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=872bf3ea-7631-4e5f-9a6a-d632213cd15c@redhat.com \
    --to=jasowang@redhat.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=brouer@redhat.com \
    --cc=john.fastabend@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.