From: Dave Taht <dave.taht@gmail.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: libreqos <libreqos@lists.bufferbloat.net>,
"aapasqual@gmail.com" <aapasqual@gmail.com>
Subject: Re: [LibreQoS] libreqos vs a vs paraqum
Date: Sat, 12 Nov 2022 09:13:58 -0800 [thread overview]
Message-ID: <CAA93jw6UVVuVMbWmDfs=6odfZGNTTfvyDTqUkfpKUSRzahm08g@mail.gmail.com> (raw)
In-Reply-To: <20221112084453.58fd2916@hermes.local>
On Sat, Nov 12, 2022 at 8:44 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Sat, 12 Nov 2022 07:54:02 -0800
> Dave Taht <dave.taht@gmail.com> wrote:
>
> > I (personally) have zero interest in dpdk and vpp. I don't want to
> > give up all the other nifty things a linux box can do by using it, so
> > I followed along on the xdp work - but I concede that these
> > technologies are probably always going to be faster than xdp, and
> > there are a ton of products deployed using it. I'd hoped someone would
> > fund open sourcing a fq_codel or cake implementation for it. (Same
> > goes for freebsd and pfsense which could use a native BQL + fq_codel
> > implementation. The BSD packet buffering scheme is really alien to
> > me). DPDK and vpp were born of the recognition that with conventional
> > processors, the bottleneck is more on the read side than the write
> > side, once you crack 10gbit.
>
> Linux and BSD has to solve the general purpose problem (lots of devices, any application, etc)
> and therefore has lots of locking an other overhead. All that overhead keeps
> it in the 1 to 4 Million packets/second/core forwarding range. With BPF some
> of this can be bypassed but then most of the interesting stuff is gone and still
> limited to 10Mpps.
All I really want is for some ethernet card to actually be able to
pick a cpu to interrupt based on LPM.
Why is even a small amount of CAM so hard?? some card must do this...
> The dedicated stuff gets much higher PPS but at a cost, limited HW suppor,
> no generic locking etc.
>
> Doing research before diving into CAKE on DPDK, the real issue is that there
> is no supported flow classification model in DPDK. There was a limited/dead library
> and doing the full classification like Linux gets harder.
I thought the panda flow dissector held great promise, generally, for
all OSes, in userspace, and even in FPGAs and chips.
https://www.sipanda.io/post/blog_aug_04
No?
--
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC
prev parent reply other threads:[~2022-11-12 17:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-12 15:54 Dave Taht
2022-11-12 16:44 ` Stephen Hemminger
2022-11-12 17:13 ` Dave Taht [this message]
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
List information: https://lists.bufferbloat.net/postorius/lists/libreqos.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw6UVVuVMbWmDfs=6odfZGNTTfvyDTqUkfpKUSRzahm08g@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=aapasqual@gmail.com \
--cc=libreqos@lists.bufferbloat.net \
--cc=stephen@networkplumber.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox