From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesper Dangaard Brouer Subject: Re: [bpf-next V2 PATCH 01/14] xdp: base API for new XDP rx-queue info concept Date: Sat, 23 Dec 2017 14:13:33 +0100 Message-ID: <20171223141333.0ecb3898@redhat.com> References: <151396262289.20006.1429172971820409456.stgit@firesoul> <151396269959.20006.11486855606275589519.stgit@firesoul> <20171222161443.241332fc@cakuba.netronome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Daniel Borkmann , Alexei Starovoitov , netdev@vger.kernel.org, dsahern@gmail.com, gospo@broadcom.com, bjorn.topel@intel.com, michael.chan@broadcom.com, brouer@redhat.com To: Jakub Kicinski Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50178 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750810AbdLWNNl (ORCPT ); Sat, 23 Dec 2017 08:13:41 -0500 In-Reply-To: <20171222161443.241332fc@cakuba.netronome.com> Sender: netdev-owner@vger.kernel.org List-ID: On Fri, 22 Dec 2017 16:14:43 -0800 Jakub Kicinski 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