netdev - Re: [bpf-next V2 PATCH 01/14] xdp: base API for new XDP rx-queue info concept

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:   Sat, 23 Dec 2017 14:13:33 +0100
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Daniel Borkmann <borkmann@...earbox.net>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        netdev@...r.kernel.org, dsahern@...il.com, gospo@...adcom.com,
        bjorn.topel@...el.com, michael.chan@...adcom.com, brouer@...hat.com
Subject: Re: [bpf-next V2 PATCH 01/14] xdp: base API for new XDP rx-queue
 info concept

On Fri, 22 Dec 2017 16:14:43 -0800
Jakub Kicinski <jakub.kicinski@...ronome.com> wrote:

> On Fri, 22 Dec 2017 18:11:39 +0100, Jesper Dangaard Brouer wrote:
> > +struct xdp_rxq_info {
> > +	struct net_device *dev;
> > +	u32 queue_index;
> > +	u32 reg_state;
> > +} ____cacheline_aligned; /* perf critical, avoid false-sharing */  
> 
> I'm assuming this is cacheline_aligned, because of some stuff you will
> add here in the future for the completion path?  (The comment could
> mention that this data is read-mostly.)  Drivers are likely to already
> have a read-mostly (or unused-mostly) section of the rx ring structure.
> Would it be possible to define this in a way that would allow people
> who carefully lay out their data path structures to save cache space?

Please lets keep such struct layout micro-optimization for later.
Having a fixed full cache-line for this struct makes it easier to avoid
any false-sharing day-1.  If we don't do this, then every time we
extend/change this struct, we (you?) have to go through every drivers
RX-ring alignment and make sure things didn't move around.  Also if
some driver developer change his own RX-ring struct layout then we/he
have to verify struct layouts.   The hole plan is this struct need to
be extended, lets help ourselves and keep it simple.  Once the size of
this struct have stabilized, then we can circle back and optimize such
stuff. Fair enough?

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer