On 23/04/14 22:56, Thomas Graf wrote:
On 04/23/2014 10:12 PM, Ethan Jackson wrote:
The problem has actually gotten worse since we've gotten rid of the
dispatcher thread. Now each thread has it's own channel per port.
I wonder if the right approach is to simply ditch the per-port
fairness in the case where mmap netlink is enabled. I.E. we simply
have one channel per thread and call it a day.
Anyways, I don't have a lot of context on this thread, so take
everything above with a grain of salt.
I agree with Ethan's statement. Even with a reduced frame size the cost
of an individual ring buffer per port is likely still too large and
we lose the benefit of zerocopy for large packets which are typically
the expensive packets.
My expectation is that such large packets shouldn't go to the userspace
very often, as ideally the TCP handshake packets already established the
flow. Do you have a use case where this is not true?
As we extend the GSO path into the upcall and make use of the new DPDK
style ofpbuf to avoid the memcpy() for the mmap case
Can you elaborate a bit more on this?
the cost of an
upcall will be minimal and the fairness issues of the upcall itself
will be minimized. However, I remember someone (Alex?) stating that the
unfairness was primarily caused by the classification.
Thomas
Ethan
On Wed, Apr 23, 2014 at 1:05 PM, Zoltan Kiss <zoltan.k...@citrix.com>
wrote:
Hi,
I would like to ask, what's the status of enabling Netlink MMAP in the
userspace? I'm interested to see this progressing, but digging the mail
archive I've found it run into scalability issues:
http://openvswitch.org/pipermail/dev/2013-December/034546.html
And also it can't handle frags at the moment properly:
http://openvswitch.org/pipermail/dev/2014-March/037337.html
I was thinking about this scalability issue, and I think maybe we
shouldn't
stick to the 16 KB frame size. I think in most cases the packets we are
actually sending up are small ones, in case of TCP the packets of the
handshakes are less than 100 bytes. And for the rest, we can call
genlmsg_new_unicast() with the full packet size, so it will fall back to
non-mmaped communication. And this would solve the frag-handling
problem as
well.
Another approach to keep the frame size lower is to pass references
to the
frags, which would point outside the ring buffer, to the actual page
(which
need to be mapped for the userspace). I don't know how feasible would
that
be, but huge linear buffers also has to be sliced up to frags.
Regards,
Zoli
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
