All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
To: Saeed Mahameed <saeed@kernel.org>
Cc: Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	Lorenzo Bianconi <lorenzo@kernel.org>,
	bpf@vger.kernel.org, netdev@vger.kernel.org, davem@davemloft.net,
	kuba@kernel.org, ast@kernel.org, daniel@iogearbox.net,
	brouer@redhat.com, alexander.duyck@gmail.com
Subject: Re: [PATCH bpf-next] net: xdp: introduce xdp_init_buff utility routine
Date: Thu, 10 Dec 2020 20:28:04 +0100	[thread overview]
Message-ID: <20201210192804.GC462213@lore-desk> (raw)
In-Reply-To: <721648a5e14dadc32629291a7d1914dd1044b7d0.camel@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 2653 bytes --]

> On Thu, 2020-12-10 at 18:59 +0100, Lorenzo Bianconi wrote:
> > On Dec 10, Maciej Fijalkowski wrote:
> > > On Thu, Dec 10, 2020 at 05:32:41PM +0100, Lorenzo Bianconi wrote:
> > > > > On Thu, Dec 10, 2020 at 04:50:42PM +0100, Lorenzo Bianconi
> > > > > wrote:
> > > > > > Introduce xdp_init_buff utility routine to initialize
> > > > > > xdp_buff data
> > > > > > structure. Rely on xdp_init_buff in all XDP capable drivers.
> > > > > 
> > > > > Hm, Jesper was suggesting two helpers, one that you implemented
> > > > > for things
> > > > > that are set once per NAPI and the other that is set per each
> > > > > buffer.
> > > > > 
> > > > > Not sure about the naming for a second one - xdp_prepare_buff ?
> > > > > xdp_init_buff that you have feels ok.
> > > > 
> > > > ack, so we can have xdp_init_buff() for initialization done once
> > > > per NAPI run and 
> > > > xdp_prepare_buff() for per-NAPI iteration initialization, e.g.
> > > > 
> > > > static inline void
> > > > xdp_prepare_buff(struct xdp_buff *xdp, unsigned char *hard_start,
> > > > 		 int headroom, int data_len)
> > > > {
> > > > 	xdp->data_hard_start = hard_start;
> > > > 	xdp->data = hard_start + headroom;
> > > > 	xdp->data_end = xdp->data + data_len;
> > > > 	xdp_set_data_meta_invalid(xdp);
> > > > }
> > > 
> > > I think we should allow for setting the data_meta as well.
> > > x64 calling convention states that first four args are placed onto
> > > registers, so to keep it fast maybe have a third helper:
> > > 
> > > static inline void
> > > xdp_prepare_buff_meta(struct xdp_buff *xdp, unsigned char
> > > *hard_start,
> > > 		      int headroom, int data_len)
> > > {
> > > 	xdp->data_hard_start = hard_start;
> > > 	xdp->data = hard_start + headroom;
> > > 	xdp->data_end = xdp->data + data_len;
> > > 	xdp->data_meta = xdp->data;
> > > }
> > > 
> > > Thoughts?
> > 
> > ack, I am fine with it. Let's wait for some feedback.
> > 
> > Do you prefer to have xdp_prepare_buff/xdp_prepare_buff_meta in the
> > same series
> > of xdp_buff_init() or is it ok to address it in a separate patch?
> > 
> 
> you only need 2
> why do you need xpd_prepare_buff_meta? that's exactly
> what xdp_set_data_meta_invalid(xdp) is all about.

IIUC what Maciej means is to avoid to overwrite xdp->data_meta with
xdp_set_data_meta_invalid() after setting it to xdp->data in
xdp_prepare_buff_meta().
I guess setting xdp->data_meta to xdp->data is valid, it means an empty meta
area.
Anyway I guess we can set xdp->data_meta to xdp->data wherever we need and just
keep xdp_prepare_buff(). Agree?

Regards,
Lorenzo

> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2020-12-10 19:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10 15:50 [PATCH bpf-next] net: xdp: introduce xdp_init_buff utility routine Lorenzo Bianconi
2020-12-10 16:05 ` Maciej Fijalkowski
2020-12-10 16:32   ` Lorenzo Bianconi
2020-12-10 16:55     ` Maciej Fijalkowski
2020-12-10 17:59       ` Lorenzo Bianconi
2020-12-10 18:42         ` Maciej Fijalkowski
2020-12-10 18:49         ` Saeed Mahameed
2020-12-10 19:28           ` Lorenzo Bianconi [this message]
2020-12-10 21:10             ` Saeed Mahameed
2020-12-10 21:24               ` Lorenzo Bianconi
2020-12-10 18:10       ` Alexander Duyck

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=20201210192804.GC462213@lore-desk \
    --to=lorenzo.bianconi@redhat.com \
    --cc=alexander.duyck@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=lorenzo@kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeed@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.