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: <52A0F95F.4010402@redhat.com>
Date:	Thu, 05 Dec 2013 23:08:31 +0100
From:	Thomas Graf <tgraf@...hat.com>
To:	Jesse Gross <jesse@...ira.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 12/04/2013 11:20 PM, Jesse Gross wrote:
> 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.

It would require to reopen sockets but I don't see that as a major
obstacle.

> 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.

Let's see where we get to with the on demand idea. Defaulting to on
is sitll possible if the number of sockets can be limited again.
--
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