[xdp-hints] Re: XDP-hints via local BTF info

[Alexander Lobakin <alexandr.lobakin@intel.com>]

From: Jesper Dangaard Brouer <jbrouer@redhat.com>
Date: Wed, 24 Nov 2021 12:54:00 +0100

> On 22/11/2021 13.57, Alexander Lobakin wrote:
> > From: Toke Høiland-Jørgensen <toke@redhat.com> Date: Fri, 19 Nov 2021
> > 15:53:39 +0100
> >
> >> Just a few additional comments, as I think y'all mostly covered
> >> everything:
> >
> > Just wanted to say that I've almost finished my iteration with cpumap
> > and veth covered.
> 
> What does this mean?
> 
> Can you consume XDP-hints in cpumap and veth, and transfer that to the
> SKB fields? (I'm very interested in this).

Exactly!
NIC driver (I'm working on a current generation NIC, so no hardware
metadata composing) builds the metadata in a known format (generic
structure), XDP prog redirects the frame to another core, function
that converts xdp_frame to sk_buff parses the metadata and fills in
skb fields.
This gives nothing on the frame size lesser than 70-90, but starting
from ~100 bytes we have a nice boost due to that CPUs don't have to
spend cycles calculating checksums (hashes etc.) anymore. So I
expect we can now benefit from GRO on cpumap and veth, thus asked
about it.
Regarding that I didn't manage to receive any performance benefits
from Hints on frame sizes lesser than beforementioned, I decided to
give an option to specify the frame size which the NIC {,driver}
should start composing metadata from. This is debatable of course,
will see.

> > I'll commit the current snapshot during the next three days ([0]). I
> > also wanted to include GRO for cpumap into this first series, but not
> > sure if it really belongs to it. WDYGT?
> 
> Everybody seems eager to hijack the thread subject
> 
> When introducing/proposing kernel changes, the discussion belong on the
> mailing-list bpf@vger.kernel.org.

Sure thing. I was just interested in a more "local" opinion, like
if by any chance you had similar thoughts or drafts etc.

> > [ snip ]
> >
> > [0] https://github.com/alobakin/linux
> 
> Kernel changes are usually send as (RFC) patches in the mailing list.

Sure thing. This repo is just an "early access", so anyone could see
what is going on before I prepare and publish any series.
There might've been a misunderstanding, but I didn't attach this
link as a "please review", it was an "I have a repo" (:

> If you want to share kernel changes via GitHub, please create a branch,
> and please avoid rebasing once shared.  I usually version my branches
> via a descriptive-name plus an increasing number, so reviewers know
> which branch is the latest code iteration.

All my changesets have separate branches, sure thing.
Not sure about rebasing thou. Many devs and kernel maintainers use
rebasing on a daily basis, without it any upstream updates mess up
everything.

> It is unusual, but we can collaborate on kernel changes via GitHub. I've
> only done with changes that are not ready for upstream submission yet,
> and as part of a (1-to-1) review over IRC (with co-workers).
> 
> I'm not sure how you expect people to help you review[0] this?

As I said, it's not a "please review" link. I'll post a link to
a separate branch here once finish the code, just for a sneak peek
for a couple days before publishing an RFC to LKML, so anyone could
leave some early comments using XDP Hints ML or GitHub itself. Some
sort of a preliminary review if you prefer :P

--

I'm sorry that I didn't have a chance yet to look at your code: it's
been a busy time. I'll dig a bit later, but anyways, thanks for all
of the work in that area

> --Jesper 

Al