netdev - Re: [PATCH RFC v3 0/8] xdp: Infrastructure to generalize XDP

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: <CALx6S358XOdPXjHUNUdnrsK-qmDVkmZXWacy1OPBJudVz31OCw@mail.gmail.com>
Date:   Tue, 21 Feb 2017 18:04:49 -0800
From:   Tom Herbert <tom@...bertland.com>
To:     Jakub Kicinski <kubakici@...pl>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH RFC v3 0/8] xdp: Infrastructure to generalize XDP

On Tue, Feb 21, 2017 at 5:29 PM, Jakub Kicinski <kubakici@...pl> wrote:
> On Tue, 21 Feb 2017 16:25:15 -0800, Tom Herbert wrote:
>> >>   - Provides a more structured environment that is extensible to new
>> >>     features while being mostly transparent to the drivers
>> >
>> > So far all features we added required explicit driver support.
>> > Checksumming support as an example will require driver changes, too.
>> > Generalized way to call programs is probably not going to buy us much?
>> >
>> Hi Jakub,
>>
>> What is the the concern with checksumming? Isn't that just an issue of
>> defining fields in xdp_data and driver populating with the appropriate
>> information?
>
> Thanks for replying!  I was just using checksumming as an example.  I
> was trying to counter the argument that the hook infrastructure will
> allow for features to be implemented mostly transparently to theom
> drivers.  I may be wrong but it seems that it doesn't buy us anything
> as far as the features which were so far discussed go.

But I still don't understand the example. In the case of checksumming
the driver just needs to populate the values in xdp_data regarding
csum. We could basically reuse the same interface as that in skbuff.
The stack then can handle the logic of verifying checksums (verifying
a csum-complete value for instance). The driver only passes
information to the stack concerning a packet, it doesn't need to act
on the information. For instance, it's not the driver's prerogative to
verify the checksum itself. In general the less drivers have to do and
the more we push complexity of common functionality into the stack,
the better.

Tom