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] [day] [month] [year] [list]

Date:	Thu, 5 Dec 2013 14:54:26 -0800
From:	Ben Pfaff <blp@...ira.com>
To:	Thomas Graf <tgraf@...hat.com>
Cc:	Jesse Gross <jesse@...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 Thu, Dec 05, 2013 at 11:08:31PM +0100, Thomas Graf wrote:
> 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.

This seems reasonable to me.

I'm not looking for perfection here, by the way, in terms of which
sockets get mmaped and which don't.  I'll be happy with any reasonable
heuristic to start out, we can always improve it later.
 
--
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