netdev - Re: [RFC PATCH 00/14] Introducing AF

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]

Date:   Wed, 15 Nov 2017 22:35:05 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Alexei Starovoitov <ast@...com>
Cc:     John Fastabend <john.fastabend@...il.com>,
        Björn Töpel <bjorn.topel@...il.com>,
        "Karlsson, Magnus" <magnus.karlsson@...el.com>,
        "Duyck, Alexander H" <alexander.h.duyck@...el.com>,
        Alexander Duyck <alexander.duyck@...il.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        michael.lundkvist@...csson.com, ravineet.singh@...csson.com,
        Daniel Borkmann <daniel@...earbox.net>,
        Netdev <netdev@...r.kernel.org>,
        Tushar Dave <tushar.n.dave@...cle.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Björn Töpel <bjorn.topel@...el.com>,
        "Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
        "Singhai, Anjali" <anjali.singhai@...el.com>,
        "Rosen, Rami" <rami.rosen@...el.com>,
        "Shaw, Jeffrey B" <jeffrey.b.shaw@...el.com>,
        "Yigit, Ferruh" <ferruh.yigit@...el.com>,
        "Zhang, Qi Z" <qi.z.zhang@...el.com>,
        David Miller <davem@...emloft.net>
Subject: Re: [RFC PATCH 00/14] Introducing AF_PACKET V4 support

On Wed, Nov 15, 2017 at 9:55 PM, Alexei Starovoitov <ast@...com> wrote:
> On 11/14/17 4:20 AM, Willem de Bruijn wrote:
>>>>>>
>>>>>>
>>>>>> * Limit the scope of the first patchset to Rx only, and introduce Tx
>>>>>>   in a separate patchset.
>>>>>
>>>>>
>>>>>
>>>>> all sounds good to me except above bit.
>>>>> I don't remember people suggesting to split it this way.
>>>>> What's the value of it without tx?
>>>>>
>>>>
>>>> We definitely need Tx for our use-cases! I'll rephrase, so the
>>>> idea was making the initial patch set without Tx *driver*
>>>> specific code, e.g. use ndo_xdp_xmit/flush at a later point.
>>>>
>>>> So AF_ZEROCOPY, the socket parts, would have Tx support.
>>>>
>>>> @John Did I recall that correctly?
>>>>
>>>
>>> Yep, that is what I said. However, on second thought, without the
>>> driver tx half I guess tx will be significantly slower.
>>
>>
>> The idea was that existing packet rings already send without
>> copying, so the benefit from device driver changes is not obvious.
>>
>> I would leave them out for now and evaluate before possibly
>> sending a separate patchset.
>
>
> are you suggesting to use new af_zerocopy for rx and old
> af_packet for tx ? imo that's too cumbersome to use.
> New interface has to be symmetrical from the start.

No, that tx can be implemented without device driver
changes. At least initially.

Unlike rx, tx does not need driver support to implement
copy avoidance, as pf_packet tx_ring already has this.

Having to go through ndo_start_xmit does introduce other
overhead, notably skb alloc. Perhaps ndo_xdp_xmit is a
better choice (but I'm not very familiar with that).

If some cost is inherent to a device-independent solution
and needs driver support to avoid it, then that can be added
in a follow-on patchset. But this one is large already without
the i40e tx patch.