lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <58A62979.1050600@gmail.com>
Date:   Thu, 16 Feb 2017 14:36:41 -0800
From:   John Fastabend <john.fastabend@...il.com>
To:     Alexander Duyck <alexander.duyck@...il.com>,
        Netdev <netdev@...r.kernel.org>
Cc:     Tom Herbert <tom@...bertland.com>,
        Alexei Starovoitov <ast@...nel.org>,
        John Fastabend <john.r.fastabend@...el.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Daniel Borkmann <daniel@...earbox.net>
Subject: Re: Questions on XDP

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
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ