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%)
>>
>> stalled-cycles-bac
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 ?!?
> >> >
> >> > Maybe you just forgot to tell perf that you want it to dec
> 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 "io
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?
>> >
>> > https://prototype-kernel.readt
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?
> >
> > https://prototype-kernel.readthedocs.io/en/latest/bpf/troubleshooting.html#perf-tool-symbols
> >
> > Enab
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
>> my performance benchmarks, with and without intel_io
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.
>>>
>>> System:
>>> 16 c
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, Björn Töpel
wrote:
From: Björn Töpel
This
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
>>> wrote:
From: Björn Töpel
This RFC introduces
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 called AF_XDP that is
optimized for high performance packet processin
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
>> Inte
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 performance packet processing and zero-copy
> > semantics. Throughput i
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 to 20x compared to V2 and
> V3 for the micro b
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 approach looks great to me.
>>
>
> Yay! :-)
>
>> The patch set i
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
>> generating packets at full 40 Gbit/s line rate.
>>
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 from AF_PACKET V4.
> At this point
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 to 20x compared to V2 and
> V3 for the micro b
> 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 poin
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 compared to V2 and
> V3 for the micro benchmarks in
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 without this RFC:
> xdp_rxq_
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 that does not know this
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 compared to V2 and
V3 for the micro benchmarks included. Would be great to get your
feedback on it. N
22 matches
Mail list logo
