From: "Michael S. Tsirkin" <mst@redhat.com>
To: John Fastabend <john.fastabend@gmail.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>,
David Miller <davem@davemloft.net>,
shrijeet@gmail.com, tom@herbertland.com, netdev@vger.kernel.org,
shm@cumulusnetworks.com, roopa@cumulusnetworks.com,
nikolay@cumulusnetworks.com
Subject: Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
Date: Fri, 28 Oct 2016 00:30:35 +0300 [thread overview]
Message-ID: <20161028002814-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <58126CF4.5090500@gmail.com>
On Thu, Oct 27, 2016 at 02:09:08PM -0700, John Fastabend wrote:
> On 16-10-27 01:55 AM, Jesper Dangaard Brouer wrote:
> > On Wed, 26 Oct 2016 13:11:22 -0400 (EDT)
> > David Miller <davem@davemloft.net> wrote:
> >
> >> From: "Michael S. Tsirkin" <mst@redhat.com>
> >> Date: Wed, 26 Oct 2016 20:07:19 +0300
> >>
> >>> On Wed, Oct 26, 2016 at 12:52:45PM -0400, David Miller wrote:
> >>>> From: "Michael S. Tsirkin" <mst@redhat.com>
> >>>> Date: Wed, 26 Oct 2016 19:36:45 +0300
> >>>>
> >>>>> On Wed, Oct 26, 2016 at 03:52:02PM +0200, Jesper Dangaard Brouer wrote:
> >>>>>> On Sat, 22 Oct 2016 04:07:23 +0000
> >>>>>> Shrijeet Mukherjee <shrijeet@gmail.com> wrote:
> >>>>>>
> >>>>>>> This patch adds support for xdp ndo and also inserts the xdp program
> >>>>>>> call into the merged RX buffers and big buffers paths
> >>>>>>
> >>>>>> I really appreciate you are doing this for virtio_net.
> >>>>>>
> >>>>>> My first question is: Is the (packet) page data writable?
> >>>>>> (MST might be able to answer?)
> >>>>>>
> >>>>>> As this is currently an XDP requirement[1].
> >>>>>
> >>>>> I'm not sure I understand what does writable mean.
> >>>>> Could you explain a bit more pls?
> >>>>> We do copy data into skb ATM but I plan to change that.
> >>>>
> >>>> The packet data area must be writable,
> >>>
> >>> This is the part I don't fully understand.
> >>> It's in RAM so of course it's writeable.
> >>
> >> Pages in SKB frag lists are not usually writable, because they share
> >> space with data from other packets the way drivers usually carve up
> >> pages to receive packets into.
> >>
> >> It is therefore illegal for the networking code to write into SKB frag
> >> pages.
> >>
> >> Pages used for XDP processed packets must not have this restriction.
> >>
> >>> We share pages between arbitrary multiple packets. I think that's
> >>> OK
> >>
> >> That's exactly what is not allowed with XDP.
> >>
> >> Each packet must be the sole user of a page, otherwise the semantics
> >> required by XDP are not met.
> >
> > Looking at the virtio_net.c code, the function call receive_big() might
> > actually be okay for XDP, unless the incoming packet is larger than
> > PAGE_SIZE and thus uses several pages (via a linked list in page->private).
> >
> > The receive_mergeable() does not look compatible with XDP.
> >
>
> Looks to me the correct conditions can be met by getting the correct
> feature negotiation to happen, specifically no VIRTIO_NET_F_MRG_RXBUF
> and one of the TSO/ECN/GSO feature bits set the big_packets flag as
> Jesper notes.
>
> Srijeet, are you going to give this a try? I'm trying to get the device
> side working by the way on the vhost interface.
>
> Thanks,
> John
Something I'd like to understand is how does XDP address the
problem that 100Byte packets are consuming 4K of memory now.
--
MST
next prev parent reply other threads:[~2016-10-27 21:30 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-22 4:07 [PATCH net-next RFC WIP] Patch for XDP support for virtio_net Shrijeet Mukherjee
2016-10-23 16:38 ` Stephen Hemminger
2016-10-24 1:51 ` Shrijeet Mukherjee
2016-10-25 1:10 ` Alexei Starovoitov
2016-10-25 17:36 ` Jakub Kicinski
2016-10-26 13:52 ` Jesper Dangaard Brouer
2016-10-26 16:36 ` Michael S. Tsirkin
2016-10-26 16:52 ` David Miller
2016-10-26 17:07 ` Michael S. Tsirkin
2016-10-26 17:11 ` David Miller
2016-10-27 8:55 ` Jesper Dangaard Brouer
2016-10-27 21:09 ` John Fastabend
2016-10-27 21:30 ` Michael S. Tsirkin [this message]
2016-10-27 21:42 ` David Miller
2016-10-27 22:25 ` Michael S. Tsirkin
2016-10-28 1:35 ` David Miller
2016-10-28 1:43 ` Alexander Duyck
2016-10-28 2:10 ` David Miller
2016-10-28 15:56 ` John Fastabend
2016-10-28 16:18 ` Jakub Kicinski
2016-10-28 18:22 ` Alexei Starovoitov
2016-10-28 20:35 ` Alexander Duyck
2016-10-28 20:42 ` Jakub Kicinski
2016-10-28 20:36 ` Jakub Kicinski
2016-10-29 3:51 ` Shrijeet Mukherjee
2016-10-29 11:25 ` Thomas Graf
2016-11-02 14:27 ` Jesper Dangaard Brouer
2016-11-03 1:28 ` Shrijeet Mukherjee
2016-11-03 4:11 ` Michael S. Tsirkin
2016-11-03 6:44 ` John Fastabend
2016-11-03 22:20 ` John Fastabend
2016-11-03 22:42 ` Michael S. Tsirkin
2016-11-03 23:29 ` John Fastabend
2016-11-04 0:34 ` Michael S. Tsirkin
2016-11-04 23:05 ` John Fastabend
2016-11-06 6:50 ` Michael S. Tsirkin
2016-10-28 17:11 ` David Miller
2016-10-30 22:53 ` Michael S. Tsirkin
2016-11-02 14:01 ` Jesper Dangaard Brouer
2016-11-02 16:06 ` Alexander Duyck
2016-10-28 0:02 ` Shrijeet Mukherjee
2016-10-28 0:46 ` Shrijeet Mukherjee
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=20161028002814-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=john.fastabend@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=roopa@cumulusnetworks.com \
--cc=shm@cumulusnetworks.com \
--cc=shrijeet@gmail.com \
--cc=tom@herbertland.com \
/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.