All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: David Miller <davem@davemloft.net>
Cc: f.fainelli@gmail.com, xdp-newbies@vger.kernel.org,
	brouer@redhat.com, Alexander Duyck <alexander.duyck@gmail.com>
Subject: Re: XDP requirements on the NIC
Date: Mon, 10 Apr 2017 22:38:35 +0200	[thread overview]
Message-ID: <20170410223835.20f68f5a@redhat.com> (raw)
In-Reply-To: <20170409.191406.134792229765947007.davem@davemloft.net>

On Sun, 09 Apr 2017 19:14:06 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Sun, 9 Apr 2017 19:05:39 -0700
> 
> > In order for a NIC and its driver to support XDP, it sounds like we need:
> > 
> > - page-based RX  
> 
> Not exactly.

The requirement is actually that the packet-page is _writable_.
These packet-pages come from the NIC DMA engine, and this complicates
keeping them writable, in the case where a RX-page is used for
containing two (or more) packets.  Careful use of the DMA API does make
it possible to page packet sharing to co-exist with XDP (consult Alex
Duyck to review such driver changes).

> > - TX multiqueue support  
> 
> Also, not really required.
> 
> What you need to be able to do is to provide enough space in each
> RX buffer for:
> 
> 1) a full size frame
> 2) 256 bytes (XDP_PACKET_HEADROOM) of headroom
> 
> This is XDP's main set of requirements, a linear buffer and enough
> room to push XDP_PACKET_HEADROOM's worth of headers.

True.
 
> Then if you want to be able to easily wrap the RX packet into an SKB
> for XDP_PASS, you need to have enough tailroom for skb_shared_info()
> which you basically give to something like build_skb().

True this is a stack requirement.

> If you look at __build_skb() it's comment states "Caller provides
> space holding head and skb_shared_info".
> 
> For XDP_TX you just have to be able to queue up a raw skb'less packet
> into your transmit queue.  TX multiqueue is not required for this to
> work.

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

           reply	other threads:[~2017-04-10 20:38 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20170409.191406.134792229765947007.davem@davemloft.net>]

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=20170410223835.20f68f5a@redhat.com \
    --to=brouer@redhat.com \
    --cc=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=xdp-newbies@vger.kernel.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.