All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Alexandre Cassen <acassen@gmail.com>,
	team lnx <teamlnxi8@gmail.com>,
	xdp-newbies@vger.kernel.org
Subject: Re: XDP packet queueing and scheduling capabilities
Date: Tue, 13 Feb 2024 17:07:20 +0100	[thread overview]
Message-ID: <87il2sfivb.fsf@toke.dk> (raw)
In-Reply-To: <d9da33bf-ecef-4470-9a8d-1b638a5ffa24@gmail.com>

Alexandre Cassen <acassen@gmail.com> writes:

> Hi Toke,
>
> here is a target with lot of interest for it : www.gtp-guard.org

Ah, seems like a cool project; thanks for the pointer!

> When dealing with mobile network data-plane, at some point you have
> ordering issues and shaping needs, so queuing is truly needed.
> Alternatively ones can implement PIFO or others built on AF_XDP but if
> dedicated bpf map covers the use-case, would be nice.

Right, I'm kinda thinking about the map type that is part of the XDP
queueing series as a general-purpose packet buffer that will enable all
kinds of features, not just queueing for forwarding. Whether it'll end
up being the PIFO map type, or a simpler one, I'm less certain about.
The PIFO abstraction may end up being too special-purpose. Opinions
welcome!

> Watching at your LPC 2022 presentation, at the end, discussions where
> made around using existing Qdisc kernel framework and find a way to
> share the path between XDP and netstack. Is it a target for adding
> PIFO, or more generally getting queuing support for XDP ?

I don't personally consider it feasible to have forwarded XDP frames
share the qdisc path. The presence of an sk_buff is too simply too
fundamentally baked into the qdisc layer. I'm hoping that the addition
of an eBPF-based qdisc will instead make it feasible to share queueing
algorithm code between the two layers (and even build forwarding paths
that can handle both by having the different BPF implementations
cooperate). And of course co-existence between XDP and stack forwarding
is important to avoid starvation, but that is already an issue for XDP
forwarding today.

-Toke


  parent reply	other threads:[~2024-02-13 16:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-12  4:27 XDP packet queueing and scheduling capabilities team lnx
2024-02-13 13:03 ` Toke Høiland-Jørgensen
2024-02-13 14:33   ` Alexandre Cassen
2024-02-13 15:01     ` Dave Taht
2024-02-13 16:07     ` Toke Høiland-Jørgensen [this message]
2024-02-13 17:31       ` Alexandre Cassen
2024-02-14 13:21         ` Toke Høiland-Jørgensen
2024-02-14 13:27   ` Marcus Wichelmann
2024-02-14 16:21     ` Toke Høiland-Jørgensen
2024-02-15 19:10   ` team lnx

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=87il2sfivb.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=acassen@gmail.com \
    --cc=teamlnxi8@gmail.com \
    --cc=xdp-newbies@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.