Le vendredi 25 novembre 2011 à 01:25 -0500, David Miller a écrit :
> From: Eric Dumazet
> Date: Fri, 25 Nov 2011 07:18:03 +0100
>
> > Le jeudi 24 novembre 2011 à 21:20 -0800, Stephen Hemminger a écrit :
> >
> >> The problem is that there are two flow classifiers, one in OpenVswitch
> >> in the k
From: Eric Dumazet
Date: Fri, 25 Nov 2011 07:18:03 +0100
> Le jeudi 24 novembre 2011 à 21:20 -0800, Stephen Hemminger a écrit :
>
>> The problem is that there are two flow classifiers, one in OpenVswitch
>> in the kernel, and the other in the user space flow manager. I think the
>> issue is that
Le jeudi 24 novembre 2011 à 21:20 -0800, Stephen Hemminger a écrit :
> The problem is that there are two flow classifiers, one in OpenVswitch
> in the kernel, and the other in the user space flow manager. I think the
> issue is that the two have different code.
We have kind of same duplication in
On Thu, 24 Nov 2011 17:30:33 -0500
jamal wrote:
> Jesse,
>
> I am going to try and respond to your comments below.
>
> On Thu, 2011-11-24 at 12:10 -0800, Jesse Gross wrote:
>
> >
> > * Switching infrastructure: As the name implies, Open vSwitch is
> > intended to be a network switch, focuse
Jesse,
I am going to try and respond to your comments below.
On Thu, 2011-11-24 at 12:10 -0800, Jesse Gross wrote:
>
> * Switching infrastructure: As the name implies, Open vSwitch is
> intended to be a network switch, focused on
> virtualization/OpenFlow/software defined networking. This me
DO YOU NEED A LOAN? CONTACT US VIA APPLICATION.___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
I realized that since Open vSwitch is so userspace-centric some of the
design considerations might not be apparent from the kernel code
alone. I did a poor job of explaining the larger picture which has
lead to some misconceptions, so I thought it would be helpful if I
gave a short overview.
One
On Nov 22, 2011, at 3:27 PM, Ben Pfaff wrote:
> +/* Performs periodic activity required by 'ofproto' that needs to be done
> + * with the least possible latency.
> + *
> + * It makes sense to call this function a couple of times per poll loop, to
> + * provide a significant performance boost on so
Looks good.
--Justin
On Nov 22, 2011, at 3:12 PM, Ben Pfaff wrote:
> This yields a 27% improvement in netperf CRR results in my tests
> versus the previous commit, which is a 52% improvement versus
> the baseline from just before the poll_fd_woke() optimization was
> removed.
> ---
> ofproto/of
I didn't experiment. The dpif-linux fds have the advantage of being
static and unchanging from one iteration to the next. It might be worth
a try later.
On Thu, Nov 24, 2011 at 10:28:45AM -0800, Justin Pettit wrote:
> Looks good. Do you think there's benefit in using epoll in the main
> poll li
Looks good. Do you think there's benefit in using epoll in the main poll
library?
--Justin
On Nov 22, 2011, at 3:12 PM, Ben Pfaff wrote:
> epoll appears to be much more efficient than poll() at least for
> static file descriptor sets. I can't otherwise explain why this
> patch increases netp
Maybe the commit message is badly phrased: the change that this
*reverts* yields a 37% benefit, so this patch actually yields a 37%
*slowdown*. But it's a necessary prerequisite for the later
improvements.
I'll reword the commit message.
On Thu, Nov 24, 2011 at 09:05:08AM -0800, Justin Pettit wr
On Nov 22, 2011, at 3:12 PM, Ben Pfaff wrote:
> /* Upcall messages. */
> struct nl_sock *upcall_socks[N_UPCALL_SOCKS];
> -int last_read_upcall;
> +uint32_t nonempty_socks;
I think it would be helpful to point out that this is a mask--either through a
comment or appending "_mask"
Looks good.
--Justin
On Nov 22, 2011, at 3:12 PM, Ben Pfaff wrote:
> This reverts commit 1e276d1a10539a8cd97d2ad63c073a9a43f0f1ef.
> The poll_fd_woke() and nl_sock_woke() function added in that commit are
> no longer used, so there is no reason to keep them in the tree.
> ---
> lib/netlink-sock
Wow. Great catch.
The description says it stopped calling poll_fd_woke() (which it's ultimately
doing), but the call in this function is nl_sock_woke().
It might be nice to explain why this improvement works over a theoretical
optimization.
--Justin
On Nov 22, 2011, at 3:12 PM, Ben Pfaff wr
Hi Justin,
I apologize, I did not intend to demean your work. There
are lots of clever ideas in there and you may have wanted
to put out something in a short period out there.
The most basic IMO is to use netlink if you are doing
it from a programmatic interface. You seem to be doing that
already
On Wed, 2011-11-23 at 08:05 -0800, John Fastabend wrote:
> > Makes sense in most cases. If you have a lot of flow setup/teardown
> > it may harm.
>
> We could have a CONFIG option to always do locking in some
> cases if thats not too ugly.
What i mean is RCU is useful when you have a substantial
On Wed, 2011-11-23 at 15:15 +0100, Eric Dumazet wrote:
>
> Or, we could stick documentation in kernel (Documentation/network/...),
> so that we give credit to contributors to this essential part of the
> network stack.
>
That would work - but i dont know how many "users" read
Documentation/netw
I cleaned up the obvious items you mentioned.
> In add_mirror_actions(), I think that the top-level assignment to
> ctx->mirrors should be removed, in favor of adding
>ctx->mirrors |= m->dup_mirrors;
> after the VLAN test inside the loop. That way, mirrors that are not
> actually used because
On Nov 23, 2011, at 3:57 PM, Ben Pfaff wrote:
> I spotted something else. In compose_output_action__(), this line:
>ctx->mirrors = ofport->bundle->mirror_out;
> doesn't look right to me.
>
> ...
>
> But I might be missing something, please check what I'm saying.
No, you're right. I should
20 matches
Mail list logo
