All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <jbrouer@redhat.com>
To: "Karlsson, Magnus" <magnus.karlsson@intel.com>,
	"Björn Töpel" <bjorn@kernel.org>,
	"Kishen Maloor" <kishen.maloor@intel.com>,
	"Desouza, Ederson" <ederson.desouza@intel.com>,
	"Alexander Lobakin" <alobakin@pm.me>
Cc: brouer@redhat.com,
	"xdp-hints@xdp-project.net" <xdp-hints@xdp-project.net>,
	bpf <bpf@vger.kernel.org>, Netdev <netdev@vger.kernel.org>
Subject: AF_XDP finding descriptor room for XDP-hints metadata size
Date: Wed, 18 Aug 2021 13:54:40 +0200	[thread overview]
Message-ID: <811eb35f-5c8b-1591-1e68-8856420b4578@redhat.com> (raw)


In previous discussions with AF_XDP maintainers (Magnus+Bjørn), I 
understood we have two challenges with metadata and BTF id.

  (1) AF_XDP doesn't know size of metadata area.
  (2) No room in xdp_desc to store the BTF-id.

Below I propose new idea to solve (1) metadata size.

To follow the discussion this is struct xdp_desc:

  /* Rx/Tx descriptor */
  struct xdp_desc {
	__u64 addr;
	__u32 len;
	__u32 options;
  };

One option (that was rejected) was to store the BTF-id in 'options' and
deduct the metadata size from BTF-id, but it was rejected as it blocks
future usages of 'options'.

The proposal by Magnus was to use a single bit in 'options' to say this
descriptor contains metadata described via BTF info. And Bjørn proposed
to store the BTF-id as the last member in metadata, as it would be
accessible via minus-4 byte offset from packet start 'addr'. And again
via BTF-id code can know the size of metadata area.

My idea is that we could store the metadata size in top-bits of 'len'
member when we have set the 'options' bit for BTF-metadata.

-Jesper


             reply	other threads:[~2021-08-18 11:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18 11:54 Jesper Dangaard Brouer [this message]
2021-08-18 12:50 ` AF_XDP finding descriptor room for XDP-hints metadata size Magnus Karlsson

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=811eb35f-5c8b-1591-1e68-8856420b4578@redhat.com \
    --to=jbrouer@redhat.com \
    --cc=alobakin@pm.me \
    --cc=bjorn@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=ederson.desouza@intel.com \
    --cc=kishen.maloor@intel.com \
    --cc=magnus.karlsson@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=xdp-hints@xdp-project.net \
    /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.