Thread (24 messages) 24 messages, 4 authors, 2022-02-22

Re: [net-next v8 2/2] net: sched: support hash/classid/cpuid selecting tx queue

From: Tonghao Zhang <hidden>
Date: 2022-02-05 07:26:38

On Mon, Jan 31, 2022 at 9:12 PM Jamal Hadi Salim [off-list ref] wrote:
On 2022-01-26 14:52, Cong Wang wrote:
quoted
You really should just use eBPF, with eBPF code you don't even need
to send anything to upstream, you can do whatever you want without
arguing with anyone. It is a win-win.
Cong,

This doesnt work in some environments. Example:

1) Some data centres (telco large and medium sized enteprises that
i have personally encountered) dont allow for anything that requires
compilation to be introduced (including ebpf).
They depend on upstream - if something is already in the kernel and
requires a script it becomes an operational issue which is a simpler
process.
This is unlike large organizations who have staff of developers
dedicated to coding stuff. Most of the folks i am talking about
have zero developers in house. But even if they did have a few,
introducing code into the kernel that has to be vetted by a
multitude of internal organizations tends to be a very
long process.
Yes, really agree with that.
2) In some cases adding new code voids the distro vendor's
support warranty and you have to pay the distro vendor to
vet and put your changes via their regression testing.
Most of these organizations are tied to one or other distro
vendor and they dont want to mess with the warranty or pay
extra fees which causes more work for them (a lot of them
have their own vetting process after the distro vendors vetting).

I am not sure what the OP's situation is - but what i described
above is _real_. If there is some extension to existing features like
skbedit and there is a good use case IMO we should allow for it.

cheers,
jamal


-- 
Best regards, Tonghao
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help