netdev - Re: [PATCH bpf-next v4] libbpf: add xsk_ring_prod__nb

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] [day] [month] [year] [list]

Date:   Thu, 22 Aug 2019 12:20:56 +0200
From:   "Eelco Chaudron" <echaudro@...hat.com>
To:     "Magnus Karlsson" <magnus.karlsson@...il.com>
Cc:     "Network Development" <netdev@...r.kernel.org>,
        "Alexei Starovoitov" <ast@...nel.org>,
        "Daniel Borkmann" <daniel@...earbox.net>,
        "Martin KaFai Lau" <kafai@...com>,
        "Song Liu" <songliubraving@...com>, "Yonghong Song" <yhs@...com>,
        "Andrii Nakryiko" <andrii.nakryiko@...il.com>
Subject: Re: [PATCH bpf-next v4] libbpf: add xsk_ring_prod__nb_free() function



On 21 Aug 2019, at 16:53, Magnus Karlsson wrote:

> On Wed, Aug 21, 2019 at 4:14 PM Magnus Karlsson
> <magnus.karlsson@...il.com> wrote:
>>
>> On Wed, Aug 21, 2019 at 3:46 PM Eelco Chaudron <echaudro@...hat.com> 
>> wrote:
>>>
>>>
>>>
>>> On 21 Aug 2019, at 15:11, Magnus Karlsson wrote:
>>>
>>>> On Wed, Aug 14, 2019 at 3:51 PM Eelco Chaudron 
>>>> <echaudro@...hat.com>
>>>> wrote:
>>>>>
>>>>> When an AF_XDP application received X packets, it does not mean X
>>>>> frames can be stuffed into the producer ring. To make it easier 
>>>>> for
>>>>> AF_XDP applications this API allows them to check how many frames 
>>>>> can
>>>>> be added into the ring.
>>>>>
>>>>> The patch below looks like a name change only, but the xsk_prod__
>>>>> prefix denotes that this API is exposed to be used by 
>>>>> applications.
>>>>>
>>>>> Besides, if you set the nb value to the size of the ring, you will
>>>>> get the exact amount of slots available, at the cost of 
>>>>> performance
>>>>> (you touch shared state for sure). nb is there to limit the
>>>>> touching of the shared state.
>>>>>
>>>>> Also the example xdpsock application has been modified to use this
>>>>> new API, so it's also able to process flows at a 1pps rate on veth
>>>>> interfaces.
>
> 1 pps! That is not that impressive ;-).
>
>>>> My apologies for the late reply and thank you for working on this. 
>>>> So
>>>> what kind of performance difference do you see with your modified
>>>> xdpsock application on a regular NIC for txpush and l2fwd? If there 
>>>> is
>>>> basically no difference or it is faster, we can go ahead and accept
>>>> this. But if the difference is large, we might consider to have two
>>>> versions of txpush and l2fwd as the regular NICs do not need this. 
>>>> Or
>>>> we optimize your code so that it becomes as fast as the previous
>>>> version.
>>>
>>> For both operation modes, I ran 5 test with and without the changes
>>> applied using an iexgb connecting to a XENA tester. The throughput
>>> numbers were within the standard deviation, so no noticeable 
>>> performance
>>> gain or drop.
>>
>> Sounds good, but let me take your patches for a run on something
>> faster, just to make sure we are CPU bound. Will get back.
>
> I ran some experiments and with two cores (app on one, softirq on
> another) there is no impact since the application core has cycles to
> spare. But if you run it on a single core the drop is 1- 2% for l2fwd.
> I think this is ok since your version is a better example and more
> correct. Just note that your patch did not apply cleanly to bpf-next,
> so please rebase it, resubmit and I will ack it.

Just sent out a v5 which is a tested rebase on the latest bpf-next.


<SNIP>