From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>,
virtualization@lists.linux-foundation.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org, "Jubran, Samih" <sameehj@amazon.com>
Subject: Re: [PATCH net-next 1/2] virtio-net: don't reserve space for vnet header for XDP
Date: Wed, 6 May 2020 05:46:59 -0400 [thread overview]
Message-ID: <20200506054619-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <3ecb558b-5281-2497-db3c-6aae7d7f882b@redhat.com>
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@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 safe to store a vnet headers before
> > xdp.data_hard_start. (The sfc driver also use this "before" area).
>
>
> The problem is if we place vnet header before data_hard_start, virtio-net
> will fail any header adjustment.
>
> Or do you mean to copy vnet header before data_hard_start before processing
> XDP?
>
>
> >
> > > there's no way for XDP to know the existence of the vnet header currently.
> > It is true that XDP is unaware of this area, which is the way it
> > should be. Currently the area will survive after calling BPF/XDP.
> > After your change it will be overwritten in xdp_frame cases.
> >
> >
> > > So let's just not reserve space for vnet header in this case.
> > I think this is a wrong approach!
> >
> > We are working on supporting GRO multi-buffer for XDP. The vnet header
> > contains GRO information (see pahole below sign).
>
>
> Another note is that since we need reserve room for skb_shared_info, GRO for
> XDP may probably lead more frag list.
>
>
> > It is currently not
> > used in the XDP case, but we will be working towards using it.
>
>
> Good to know that, but I think it can only work when the packet is not
> modified by XDP?
>
>
> > There
> > are a lot of unanswered questions on how this will be implemented.
> > Thus, I cannot layout how we are going to leverage this info yet, but
> > your patch are killing this info, which IHMO is going in the wrong
> > direction.
>
>
> I can copy vnet header ahead of data_hard_start, does it work for you?
>
> Thanks
That's likely to be somewhat expensive.
>
> >
> >
> > > Cc: Jesper Dangaard Brouer <brouer@redhat.com>
> > > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > > ---
> > > drivers/net/virtio_net.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > index 11f722460513..98dd75b665a5 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -684,8 +684,8 @@ static struct sk_buff *receive_small(struct net_device *dev,
> > > page = xdp_page;
> > > }
> > > - xdp.data_hard_start = buf + VIRTNET_RX_PAD + vi->hdr_len;
> > > - xdp.data = xdp.data_hard_start + xdp_headroom;
> > > + xdp.data_hard_start = buf + VIRTNET_RX_PAD;
> > > + xdp.data = xdp.data_hard_start + xdp_headroom + vi->hdr_len;
> > > xdp.data_end = xdp.data + len;
> > > xdp.data_meta = xdp.data;
> > > xdp.rxq = &rq->xdp_rxq;
> > > @@ -845,7 +845,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> > > * the descriptor on if we get an XDP_TX return code.
> > > */
> > > data = page_address(xdp_page) + offset;
> > > - xdp.data_hard_start = data - VIRTIO_XDP_HEADROOM + vi->hdr_len;
> > > + xdp.data_hard_start = data - VIRTIO_XDP_HEADROOM;
> > > xdp.data = data + vi->hdr_len;
> > > xdp.data_end = xdp.data + (len - vi->hdr_len);
> > > xdp.data_meta = xdp.data;
> >
> >
next prev parent reply other threads:[~2020-05-06 9:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-06 6:16 [PATCH net-next 1/2] virtio-net: don't reserve space for vnet header for XDP Jason Wang
2020-05-06 6:16 ` [PATCH net-next 2/2] virtio-net: fix the XDP truesize calculation for mergeable buffers Jason Wang
2020-05-06 7:37 ` Michael S. Tsirkin
2020-05-06 8:21 ` Jason Wang
2020-05-06 12:08 ` Michael S. Tsirkin
2020-05-08 1:54 ` Jason Wang
2020-05-06 7:53 ` [PATCH net-next 1/2] virtio-net: don't reserve space for vnet header for XDP Michael S. Tsirkin
2020-05-06 8:19 ` Jason Wang
2020-05-06 9:54 ` Michael S. Tsirkin
2020-05-08 1:56 ` Jason Wang
2020-05-06 8:21 ` Jesper Dangaard Brouer
2020-05-06 8:34 ` Jason Wang
2020-05-06 9:46 ` Michael S. Tsirkin [this message]
2020-05-08 1:59 ` Jason Wang
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=20200506054619-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sameehj@amazon.com \
--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.