Questions on XDP

So I'm in the process of working on enabling XDP for the Intel NICs
and I had a few questions so I just thought I would put them out here
to try and get everything sorted before I paint myself into a corner.

So my first question is why does the documentation mention 1 frame per
page for XDP?  Is this with the intention at some point to try and
support page flipping into user space, or is it supposed to have been
for the use with an API such as the AF_PACKET mmap stuff?  If I am not
mistaken the page flipping has been tried in the past and failed, and
as far as the AF_PACKET stuff my understanding is that the pages had
to be mapped beforehand so it doesn't gain us anything without a
hardware offload to a pre-mapped queue.

Second I was wondering about supporting jumbo frames and scatter
gather.  Specifically if I let XDP handle the first 2-3K of a frame,
and then processed the remaining portion of the frame following the
directive set forth based on the first frame would that be good enough
to satisfy XDP or do I actually have to support 1 linear buffer
always.

Finally I was looking at xdp_adjust_head.  From what I can tell all
that is technically required to support it is allowing the head to be
adjusted either in or out.  I'm assuming there is some amount of
padding that is preferred.  With the setup I have currently I am
guaranteeing at least NET_SKB_PAD + NET_IP_ALIGN, however I have found
that there should be enough room for 192 bytes on an x86 system if I
am using a 2K buffer.  I'm just wondering if that is enough padding or
if we need more for XDP.

Anyway sorry for the stupid questions but I haven't been paying close
of attention to this and was mostly focused on the DMA bits needed to
support this so now I am playing catch-up.

- Alex

On 17-02-16 12:41 PM, Alexander Duyck wrote:

So I'm in the process of working on enabling XDP for the Intel NICs
and I had a few questions so I just thought I would put them out here
to try and get everything sorted before I paint myself into a corner.

Added Daniel.

So my first question is why does the documentation mention 1 frame per
page for XDP?  Is this with the intention at some point to try and
support page flipping into user space, or is it supposed to have been
for the use with an API such as the AF_PACKET mmap stuff?  If I am not
mistaken the page flipping has been tried in the past and failed, and
as far as the AF_PACKET stuff my understanding is that the pages had
to be mapped beforehand so it doesn't gain us anything without a
hardware offload to a pre-mapped queue.

+1 here. The implementation for virtio does not use page per packet and
works fine. And agreed AF_PACKET does not require it.

If anyone has page-flipping code I would be happy to benchmark it.

Second I was wondering about supporting jumbo frames and scatter
gather.  Specifically if I let XDP handle the first 2-3K of a frame,
and then processed the remaining portion of the frame following the
directive set forth based on the first frame would that be good enough
to satisfy XDP or do I actually have to support 1 linear buffer
always.

For now yes. But, I need a solution to support 64k TSO packets or else
VM to VM traffic is severely degraded in my vswitch use case.

Finally I was looking at xdp_adjust_head.  From what I can tell all
that is technically required to support it is allowing the head to be
adjusted either in or out.  I'm assuming there is some amount of
padding that is preferred.  With the setup I have currently I am
guaranteeing at least NET_SKB_PAD + NET_IP_ALIGN, however I have found
that there should be enough room for 192 bytes on an x86 system if I
am using a 2K buffer.  I'm just wondering if that is enough padding or
if we need more for XDP.

Not surprisingly I'm also in agreement here it would help the ixgbe
implementation out.

Anyway sorry for the stupid questions but I haven't been paying close
of attention to this and was mostly focused on the DMA bits needed to
support this so now I am playing catch-up.

None of the above are stupid IMO. Let me send out the ixgbe implementation
later this afternoon so you can have a look at my interpretation of the
rules.

- Alex

On Thu, 16 Feb 2017 14:36:41 -0800
John Fastabend [off-list ref] wrote:

On 17-02-16 12:41 PM, Alexander Duyck wrote:

quoted

So I'm in the process of working on enabling XDP for the Intel NICs
and I had a few questions so I just thought I would put them out here
to try and get everything sorted before I paint myself into a corner.
  
So my first question is why does the documentation mention 1 frame per
page for XDP?  

Yes, XDP defines upfront a memory model where there is only one packet
per page[1], please respect that!

This is currently used/needed for fast-direct recycling of pages inside
the driver for XDP_DROP and XDP_TX, _without_ performing any atomic
refcnt operations on the page. E.g. see mlx4_en_rx_recycle().

This is also about controlling the cache-coherency state of the
struct-page cache-line.  (With two (or-more) packets per page,
the struct-page cache-line will be jumping around.) Controlling this is
essential when packets are transferred between CPUs. We need an
architecture were we can control this, please.

[1] https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/design/requirements.html#page-per-packet

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

On Sat, 2017-02-18 at 17:34 +0100, Jesper Dangaard Brouer wrote:

On Thu, 16 Feb 2017 14:36:41 -0800
John Fastabend [off-list ref] wrote:

quoted

On 17-02-16 12:41 PM, Alexander Duyck wrote:

quoted

So I'm in the process of working on enabling XDP for the Intel NICs
and I had a few questions so I just thought I would put them out here
to try and get everything sorted before I paint myself into a corner.
  
So my first question is why does the documentation mention 1 frame per
page for XDP?  

Yes, XDP defines upfront a memory model where there is only one packet
per page[1], please respect that!

This is currently used/needed for fast-direct recycling of pages inside
the driver for XDP_DROP and XDP_TX, _without_ performing any atomic
refcnt operations on the page. E.g. see mlx4_en_rx_recycle().

XDP_DROP does not require having one page per frame.

(Look after my recent mlx4 patch series if you need to be convinced)

Only XDP_TX is.

This requirement makes XDP useless (very OOM likely) on arches with 64K
pages.

On Sat, Feb 18, 2017 at 9:41 AM, Eric Dumazet [off-list ref] wrote:

On Sat, 2017-02-18 at 17:34 +0100, Jesper Dangaard Brouer wrote:

quoted

On Thu, 16 Feb 2017 14:36:41 -0800
John Fastabend [off-list ref] wrote:

quoted

On 17-02-16 12:41 PM, Alexander Duyck wrote:

quoted

So I'm in the process of working on enabling XDP for the Intel NICs
and I had a few questions so I just thought I would put them out here
to try and get everything sorted before I paint myself into a corner.

So my first question is why does the documentation mention 1 frame per
page for XDP?

Yes, XDP defines upfront a memory model where there is only one packet
per page[1], please respect that!

This is currently used/needed for fast-direct recycling of pages inside
the driver for XDP_DROP and XDP_TX, _without_ performing any atomic
refcnt operations on the page. E.g. see mlx4_en_rx_recycle().

XDP_DROP does not require having one page per frame.

Agreed.

(Look after my recent mlx4 patch series if you need to be convinced)

Only XDP_TX is.

This requirement makes XDP useless (very OOM likely) on arches with 64K
pages.

Actually I have been having a side discussion with John about XDP_TX.
Looking at the Mellanox way of doing it I am not entirely sure it is
useful.  It looks good for benchmarks but that is about it.  Also I
don't see it extending out to the point that we would be able to
exchange packets between interfaces which really seems like it should
be the ultimate goal for XDP_TX.

It seems like eventually we want to be able to peel off the buffer and
send it to something other than ourselves.  For example it seems like
it might be useful at some point to use XDP to do traffic
classification and have it route packets between multiple interfaces
on a host and it wouldn't make sense to have all of them map every
page as bidirectional because it starts becoming ridiculous if you
have dozens of interfaces in a system.

As per our original discussion at netconf if we want to be able to do
XDP Tx with a fully lockless Tx ring we needed to have a Tx ring per
CPU that is performing XDP.  The Tx path will end up needing to do the
map/unmap itself in the case of physical devices but the expense of
that can be somewhat mitigated on x86 at least by either disabling the
IOMMU or using identity mapping.  I think this might be the route
worth exploring as we could then start looking at doing things like
implementing bridges and routers in XDP and see what performance gains
can be had there.

Also as far as the one page per frame it occurs to me that you will
have to eventually deal with things like frame replication.  Once that
comes into play everything becomes much more difficult because the
recycling doesn't work without some sort of reference counting, and
since the device interrupt can migrate you could end up with clean-up
occurring on a different CPUs so you need to have some sort of
synchronization mechanism.

Thanks.

- Alex

On 17-02-18 10:18 AM, Alexander Duyck wrote:

On Sat, Feb 18, 2017 at 9:41 AM, Eric Dumazet [off-list ref] wrote:

quoted

On Sat, 2017-02-18 at 17:34 +0100, Jesper Dangaard Brouer wrote:

quoted

On Thu, 16 Feb 2017 14:36:41 -0800
John Fastabend [off-list ref] wrote:

quoted

On 17-02-16 12:41 PM, Alexander Duyck wrote:

quoted

So I'm in the process of working on enabling XDP for the Intel NICs
and I had a few questions so I just thought I would put them out here
to try and get everything sorted before I paint myself into a corner.

So my first question is why does the documentation mention 1 frame per
page for XDP?

Yes, XDP defines upfront a memory model where there is only one packet
per page[1], please respect that!

This is currently used/needed for fast-direct recycling of pages inside
the driver for XDP_DROP and XDP_TX, _without_ performing any atomic
refcnt operations on the page. E.g. see mlx4_en_rx_recycle().

Alex, does your pagecnt_bias trick resolve this? It seems to me that the
recycling is working in ixgbe patches just fine (at least I never see the
allocator being triggered with simple XDP programs). The biggest win for
me right now is to avoid the dma mapping operations.

quoted

XDP_DROP does not require having one page per frame.

Agreed.

quoted

(Look after my recent mlx4 patch series if you need to be convinced)

Only XDP_TX is.

I'm still not sure what page per packet buys us on XDP_TX. What was the
explanation again?

quoted

This requirement makes XDP useless (very OOM likely) on arches with 64K
pages.

Actually I have been having a side discussion with John about XDP_TX.
Looking at the Mellanox way of doing it I am not entirely sure it is
useful.  It looks good for benchmarks but that is about it.  Also I
don't see it extending out to the point that we would be able to
exchange packets between interfaces which really seems like it should
be the ultimate goal for XDP_TX.

This is needed if we want XDP to be used for vswitch use cases. We have
a patch running on virtio but really need to get it working on real
hardware before we push it.

It seems like eventually we want to be able to peel off the buffer and
send it to something other than ourselves.  For example it seems like
it might be useful at some point to use XDP to do traffic
classification and have it route packets between multiple interfaces
on a host and it wouldn't make sense to have all of them map every
page as bidirectional because it starts becoming ridiculous if you
have dozens of interfaces in a system.

As per our original discussion at netconf if we want to be able to do
XDP Tx with a fully lockless Tx ring we needed to have a Tx ring per
CPU that is performing XDP.  The Tx path will end up needing to do the
map/unmap itself in the case of physical devices but the expense of
that can be somewhat mitigated on x86 at least by either disabling the
IOMMU or using identity mapping.  I think this might be the route
worth exploring as we could then start looking at doing things like
implementing bridges and routers in XDP and see what performance gains
can be had there.

One issue I have with TX ring per CPU per device is in my current use
case I have 2k tap/vhost devices and need to scale up to more than that.
Taking the naive approach and making each tap/vhost create a per cpu
ring would be 128k rings on my current dev box. I think locking could
be optional without too much difficulty.

Also as far as the one page per frame it occurs to me that you will
have to eventually deal with things like frame replication.  Once that
comes into play everything becomes much more difficult because the
recycling doesn't work without some sort of reference counting, and
since the device interrupt can migrate you could end up with clean-up
occurring on a different CPUs so you need to have some sort of
synchronization mechanism.

Thanks.

- Alex