netdev - Re: [PATCH RFC net-next] openvswitch: Queue upcalls to userspace in per-port round-robin order

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180803230108.GU29662@ovn.org>
Date:   Fri, 3 Aug 2018 16:01:08 -0700
From:   Ben Pfaff <blp@....org>
To:     Stefano Brivio <sbrivio@...hat.com>
Cc:     Matteo Croce <mcroce@...hat.com>,
        Pravin B Shelar <pshelar@....org>, jpettit@...are.com,
        gvrose8192@...il.com, netdev <netdev@...r.kernel.org>,
        dev@...nvswitch.org, Jiri Benc <jbenc@...hat.com>,
        Aaron Conole <aconole@...hat.com>
Subject: Re: [PATCH RFC net-next] openvswitch: Queue upcalls to userspace in
 per-port round-robin order

On Fri, Aug 03, 2018 at 06:52:41PM +0200, Stefano Brivio wrote:
> On Tue, 31 Jul 2018 15:06:57 -0700 Ben Pfaff <blp@....org> wrote:
> > My current thought is that any fairness scheme we implement directly in
> > the kernel is going to need to evolve over time.  Maybe we could do
> > something flexible with BPF and maps, instead of hard-coding it.
> 
> Honestly, I fail to see what else we might want to do here, other than
> adding a simple mechanism for fairness, to solve the specific issue at
> hand. Flexibility would probably come at a higher cost. We could easily
> make limits configurable if needed. Do you have anything else in mind?

I think that a simple mechanism for fairness is fine.  The direction of
extensibility that makes me anxious is how to decide what matters for
fairness.  So far, we've talked about per-vport fairness.  That works
pretty well for packets coming in from virtual interfaces where each
vport represents a separate VM.  It does not work well if the traffic
filling your queues all comes from a single physical port because some
source of traffic is sending traffic at a high rate.  In that case,
you'll do a lot better if you do fairness based on the source 5-tuple.
But if you're doing network virtualization, then the outer source
5-tuples won't necessarily vary much and you'd be better off looking at
the VNI and maybe some Geneve TLV options and maybe the inner 5-tuple...

I would be very pleased if we could integrate a simple mechanism for
fairness, based for now on some simple criteria like the source port,
but thinking ahead to how we could later make it gracefully extensible
to consider more general and possibly customizable criteria.

Thanks,

Ben.