Re: [RFC PATCH 00/24] Introducing AF_XDP support

Hi Jesper, Thanks for the comments. >> I assume this xdpsock code is small and should all fit into the icache. >> However, doing another perf stat on xdpsock l2fwd shows >> >> 13,720,109,581 stalled-cycles-frontend # 60.01% frontend cycles >> idle (23.82%) >> >>

Re: [RFC PATCH 00/24] Introducing AF_XDP support

On Tue, 27 Mar 2018 17:06:50 -0700 William Tu wrote: > On Tue, Mar 27, 2018 at 2:37 AM, Jesper Dangaard Brouer > wrote: > > On Mon, 26 Mar 2018 14:58:02 -0700 > > William Tu wrote: > > > >> > Again high count for NMI ?!? > >> > > >>

Re: [RFC PATCH 00/24] Introducing AF_XDP support

> Indeed. Intel iommu has least effect on RX because of premap/recycle. > But TX dma map and unmap is really expensive! > >> >> Basically the IOMMU can make creating/destroying a DMA mapping really >> expensive. The easiest way to work around it in the case of the Intel >> IOMMU is to boot with

Re: [RFC PATCH 00/24] Introducing AF_XDP support

On Tue, Mar 27, 2018 at 2:37 AM, Jesper Dangaard Brouer wrote: > On Mon, 26 Mar 2018 14:58:02 -0700 > William Tu wrote: > >> > Again high count for NMI ?!? >> > >> > Maybe you just forgot to tell perf that you want it to decode the >> > bpf_prog correctly?

Re: [RFC PATCH 00/24] Introducing AF_XDP support

On Mon, 26 Mar 2018 14:58:02 -0700 William Tu wrote: > > Again high count for NMI ?!? > > > > Maybe you just forgot to tell perf that you want it to decode the > > bpf_prog correctly? > > > >

Re: [RFC PATCH 00/24] Introducing AF_XDP support

2018-03-27 1:03 GMT+02:00 Alexander Duyck : > On Mon, Mar 26, 2018 at 3:54 PM, Tushar Dave wrote: [...] >> >> Whats the implication here. Should IOMMU be disabled? >> I'm asking because I do see a huge difference while running pktgen test for

Re: [RFC PATCH 00/24] Introducing AF_XDP support

2018-03-26 23:58 GMT+02:00 William Tu : > Hi Jesper, > > Thanks a lot for your prompt reply. > >>> Hi, >>> I also did an evaluation of AF_XDP, however the performance isn't as >>> good as above. >>> I'd like to share the result and see if there are some tuning suggestions. >>>

Re: [RFC PATCH 00/24] Introducing AF_XDP support

On 03/26/2018 04:03 PM, Alexander Duyck wrote: On Mon, Mar 26, 2018 at 3:54 PM, Tushar Dave wrote: On 03/26/2018 09:38 AM, Jesper Dangaard Brouer wrote: On Mon, 26 Mar 2018 09:06:54 -0700 William Tu wrote: On Wed, Jan 31, 2018 at 5:53 AM,

Re: [RFC PATCH 00/24] Introducing AF_XDP support

On Mon, Mar 26, 2018 at 3:54 PM, Tushar Dave wrote: > > > On 03/26/2018 09:38 AM, Jesper Dangaard Brouer wrote: >> >> >> On Mon, 26 Mar 2018 09:06:54 -0700 William Tu wrote: >> >>> On Wed, Jan 31, 2018 at 5:53 AM, Björn Töpel

Re: [RFC PATCH 00/24] Introducing AF_XDP support

On 03/26/2018 09:38 AM, Jesper Dangaard Brouer wrote: On Mon, 26 Mar 2018 09:06:54 -0700 William Tu wrote: On Wed, Jan 31, 2018 at 5:53 AM, Björn Töpel wrote: From: Björn Töpel This RFC introduces a new address family

Re: [RFC PATCH 00/24] Introducing AF_XDP support

Hi Jesper, Thanks a lot for your prompt reply. >> Hi, >> I also did an evaluation of AF_XDP, however the performance isn't as >> good as above. >> I'd like to share the result and see if there are some tuning suggestions. >> >> System: >> 16 core, Intel(R) Xeon(R) CPU E5-2440 v2 @ 1.90GHz >>

Re: [RFC PATCH 00/24] Introducing AF_XDP support

On Mon, 26 Mar 2018 09:06:54 -0700 William Tu wrote: > On Wed, Jan 31, 2018 at 5:53 AM, Björn Töpel wrote: > > From: Björn Töpel > > > > This RFC introduces a new address family called AF_XDP that is > > optimized for high

Re: [RFC PATCH 00/24] Introducing AF_XDP support

On Wed, Jan 31, 2018 at 5:53 AM, Björn Töpel wrote: > From: Björn Töpel > > This RFC introduces a new address family called AF_XDP that is > optimized for high performance packet processing and zero-copy > semantics. Throughput improvements can be up

Re: [RFC PATCH 00/24] Introducing AF_XDP support

On Wed, Feb 7, 2018 at 4:28 PM, Björn Töpel wrote: > 2018-02-07 16:54 GMT+01:00 Willem de Bruijn : >>> We realized, a bit late maybe, that 24 patches is a bit mouthful, so >>> let me try to make it more palatable. >> >> Overall, this

Re: [RFC PATCH 00/24] Introducing AF_XDP support

2018-02-07 18:59 GMT+01:00 Tom Herbert : > On Wed, Jan 31, 2018 at 5:53 AM, Björn Töpel wrote: [...] >> >> Below are the results in Mpps of the I40E NIC benchmark runs for 64 >> byte packets, generated by commercial packet generator HW that is >>

Re: [RFC PATCH 00/24] Introducing AF_XDP support

2018-02-07 16:54 GMT+01:00 Willem de Bruijn : >> We realized, a bit late maybe, that 24 patches is a bit mouthful, so >> let me try to make it more palatable. > > Overall, this approach looks great to me. > Yay! :-) > The patch set incorporates all the feedback

Re: [RFC PATCH 00/24] Introducing AF_XDP support

On Wed, Jan 31, 2018 at 5:53 AM, Björn Töpel wrote: > From: Björn Töpel > > This RFC introduces a new address family called AF_XDP that is > optimized for high performance packet processing and zero-copy > semantics. Throughput improvements can be up

Re: [RFC PATCH 00/24] Introducing AF_XDP support

> We realized, a bit late maybe, that 24 patches is a bit mouthful, so > let me try to make it more palatable. Overall, this approach looks great to me. The patch set incorporates all the feedback from AF_PACKET V4. At this point I don't have additional high-level interface comments. As you

Re: [RFC PATCH 00/24] Introducing AF_XDP support

2018-01-31 14:53 GMT+01:00 Björn Töpel : > From: Björn Töpel > > This RFC introduces a new address family called AF_XDP that is > optimized for high performance packet processing and zero-copy > semantics. Throughput improvements can be up to 20x

Re: [RFC PATCH 00/24] Introducing AF_XDP support

On Wed, 31 Jan 2018 14:53:32 +0100 Björn Töpel wrote: > Below are the results in Mpps of the I40E NIC benchmark runs for 64 > byte packets, generated by commercial packet generator HW that is > generating packets at full 40 Gbit/s line rate. > > XDP baseline numbers

Re: [RFC PATCH 00/24] Introducing AF_XDP support

On Wed, 31 Jan 2018 14:53:32 +0100 Björn Töpel wrote: > * In this RFC, do not use an XDP_REDIRECT action other than > bpf_xdpsk_redirect for XDP_DRV_ZC. This is because a zero-copy > allocated buffer will then be sent to a cpu id / queue_pair through > ndo_xdp_xmit