netdev - Re: [PATCH openvswitch v3] netlink: Implement & enable memory mapped netlink i/o

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: <CAEP_g=8jMEsrOEpU=LTsfp93RaOowR5DfRB=dzQ-OJEsAVmm0g@mail.gmail.com>
Date:	Wed, 4 Dec 2013 14:20:53 -0800
From:	Jesse Gross <jesse@...ira.com>
To:	Thomas Graf <tgraf@...hat.com>
Cc:	Ben Pfaff <blp@...ira.com>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>,
	netdev <netdev@...r.kernel.org>,
	Daniel Borkmann <dborkman@...hat.com>, ffusco@...hat.com,
	fleitner@...hat.com, Cong Wang <xiyou.wangcong@...il.com>
Subject: Re: [PATCH openvswitch v3] netlink: Implement & enable memory mapped
 netlink i/o

On Wed, Dec 4, 2013 at 1:48 PM, Thomas Graf <tgraf@...hat.com> wrote:
> On 12/04/2013 07:08 PM, Ben Pfaff wrote:
>> if one can come up with a
>> good heuristic to decide which sockets should be mmaped.  One place
>> one could start would be to mmap the sockets that correspond to
>> physical ports.
>
>
> That sounds reasonable, e.g. I would assume ports connected to tap
> devices to produce only a limited number of upcalls anyway.
>
> We can also consider enabling/disabling mmaped rings on demand based
> on upcall statistics.

If enabling rings on demand can be done cleanly that might be best
solution. To me, it seems difficult to generalize the upcall
characteristics based on port type.

>> Maybe you mean that we should only create 16 or 32 Netlink sockets,
>> and divide the datapath ports among those sockets.  OVS once used this
>> approach.  We stopped using it because it has problems with fairness:
>> if two ports are assigned to one socket, and one of those ports has a
>> huge volume of new flows (or otherwise sends a lot of packets to
>> userspace), then it can drown out the occasional packet from the other
>> port.  We keep talking about new, more flexible approaches to
>> achieving fairness, though, and maybe some of those approaches would
>> allow us to reduce the number of sockets we need, which would make
>> mmaping all of them feasible.
>
>
> I can see the fairness issue. It will result in a large amount of open
> file descriptors though. I doubt this will scale much beyond 16K ports,
> correct?

16K ports/sockets would seem to be a good upper bound. However, there
are a couple of factors that might affect that number in the future.
The first is that port might not be fine-grained enough - for example,
on an uplink port it would be better to look at MAC or IP address to
enforce fairness, which would tend to expand the number of sockets
necessary (although there obviously won't be a 1:1 mapping, which
means that we might have to come up with a more clever assignment
algorithm). The second is that Alex has been working on a userspace
mechanism for enforcing fairness (you probably have seen his recent
patches on the mailing list), which could reduce the number of unique
queues from the kernel.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html