|| ||Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w-AT-public.gmane.org> |
|| ||Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q-AT-public.gmane.org> |
|| ||Re: [GIT PULL v2] Open vSwitch |
|| ||Wed, 23 Nov 2011 09:12:22 +0100|
|| ||dev-yBygre7rU0TnMu66kgdUjQ-AT-public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA-AT-public.gmane.org,
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q-AT-public.gmane.org>|
|| ||Article, Thread
Le mercredi 23 novembre 2011 à 15:54 +0800, Herbert Xu a écrit :
> David Miller <firstname.lastname@example.org> wrote:
> > I would like to see some discussion wrt. Jamal's feedback, which is that
> > a lot of the side-band functionality added by this code is either 1) already
> > doable with packet scheduler actions or 2) should be implemented there.
> I mostly agree with Jamal. As far as the concept of a policy
> lookup cache goes (which appears to be at the core of OVS), this
> almost fits exactly onto a u32 hash table. All that would be needed
> is to add the tail end of the policies, e.g., with new packet
> However, this is purely based on my conceptual view of OVS, which
> may or may not be accurate. I'll dig into the patches over the
> next couple of days to see if they could be easily turned into
> packet actions or whether this is difficult for reasons that we
> have not yet discovered.
I had no time to look at OVS, but current tc model is not scalable,
everything is performed under a queue lock.
Maybe its time to redesign a new model, based on modern techniques.
By the way, we seriously lack good documentation on tc, not counting
many features. Code might be there, but without documenation, working
samples, who can use it ?
Take a look at last cls_flow extension, and try to use it on a real
setup, you'll find its almost not possible...
dev mailing list
to post comments)