All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Daniel Borkmann <borkmann@iogearbox.net>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	netdev@vger.kernel.org, dsahern@gmail.com, gospo@broadcom.com,
	bjorn.topel@intel.com, michael.chan@broadcom.com,
	brouer@redhat.com
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	[thread overview]
Message-ID: <20171223141333.0ecb3898@redhat.com> (raw)
In-Reply-To: <20171222161443.241332fc@cakuba.netronome.com>

On Fri, 22 Dec 2017 16:14:43 -0800
Jakub Kicinski <jakub.kicinski@netronome.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

  reply	other threads:[~2017-12-23 13:13 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-22 17:11 [bpf-next V2 PATCH 00/14] xdp: new XDP rx-queue info concept Jesper Dangaard Brouer
2017-12-22 17:11 ` [bpf-next V2 PATCH 01/14] xdp: base API for " Jesper Dangaard Brouer
2017-12-23  0:14   ` Jakub Kicinski
2017-12-23 13:13     ` Jesper Dangaard Brouer [this message]
2017-12-22 17:11 ` [bpf-next V2 PATCH 02/14] xdp/mlx5: setup xdp_rxq_info Jesper Dangaard Brouer
2017-12-22 17:11 ` [bpf-next V2 PATCH 03/14] i40e: " Jesper Dangaard Brouer
2017-12-22 17:11   ` [Intel-wired-lan] " Jesper Dangaard Brouer
2017-12-22 17:11 ` [bpf-next V2 PATCH 04/14] ixgbe: " Jesper Dangaard Brouer
2017-12-22 17:11   ` [Intel-wired-lan] " Jesper Dangaard Brouer
2017-12-22 17:12 ` [bpf-next V2 PATCH 05/14] xdp/qede: setup xdp_rxq_info and intro xdp_rxq_info_is_reg Jesper Dangaard Brouer
2017-12-27 10:37   ` Chopra, Manish
2017-12-27 11:58     ` Jesper Dangaard Brouer
2017-12-22 17:12 ` [bpf-next V2 PATCH 06/14] mlx4: setup xdp_rxq_info Jesper Dangaard Brouer
2017-12-24 11:11   ` Tariq Toukan
2017-12-22 17:12 ` [bpf-next V2 PATCH 07/14] bnxt_en: " Jesper Dangaard Brouer
2017-12-22 17:12 ` [bpf-next V2 PATCH 08/14] nfp: " Jesper Dangaard Brouer
2017-12-22 17:12 ` [bpf-next V2 PATCH 09/14] thunderx: " Jesper Dangaard Brouer
2017-12-22 17:12   ` Jesper Dangaard Brouer
2017-12-22 17:12 ` [bpf-next V2 PATCH 10/14] tun: " Jesper Dangaard Brouer
2017-12-22 17:12 ` [bpf-next V2 PATCH 11/14] virtio_net: " Jesper Dangaard Brouer
2017-12-22 17:12 ` Jesper Dangaard Brouer
2017-12-26 11:20   ` Jesper Dangaard Brouer
2017-12-26 11:20   ` Jesper Dangaard Brouer
2017-12-22 17:12 ` [bpf-next V2 PATCH 12/14] xdp: generic XDP handling of xdp_rxq_info Jesper Dangaard Brouer
2017-12-22 17:12 ` [bpf-next V2 PATCH 13/14] bpf: finally expose xdp_rxq_info to XDP bpf-programs Jesper Dangaard Brouer
2017-12-23  4:50   ` Alexei Starovoitov
2017-12-22 17:12 ` [bpf-next V2 PATCH 14/14] samples/bpf: program demonstrating access to xdp_rxq_info Jesper Dangaard Brouer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171223141333.0ecb3898@redhat.com \
    --to=brouer@redhat.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bjorn.topel@intel.com \
    --cc=borkmann@iogearbox.net \
    --cc=dsahern@gmail.com \
    --cc=gospo@broadcom.com \
    --cc=jakub.kicinski@netronome.com \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.