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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170221182341.4b2dd0c8@cakuba.netronome.com>
Date:   Tue, 21 Feb 2017 18:23:41 -0800
From:   Jakub Kicinski <kubakici@...pl>
To:     Tom Herbert <tom@...bertland.com>
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, 21 Feb 2017 18:04:49 -0800, Tom Herbert wrote:
> 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.

Sorry, I thought your patchset abstracts away populating struct xdp. 
So my initial statement should have read "Checksumming will require
driver changes, only".  Yes, drivers will just have to populate the
appropriate XDP buffer field.  What are the XDP features you foresee
this hook infrastructure to help drivers with?