On 23 August 2014 07:59, Ben Pfaff wrote:
> n_umaps is now a hard-coded constant, but a lot of the code assumes
> that it can vary. It would be very slightly simpler to actually use a
> macro or enum to define the fixed size instead of a variable. It
> would also allow better code generation in
On 23 August 2014 08:01, Ben Pfaff wrote:
> On Thu, Aug 21, 2014 at 05:41:59PM +1200, Joe Stringer wrote:
> > Currently, ukeys are protected during revalidator_sweep__() as only one
> > thread accesses the ukey at a time. This is ensured using barriers:
> > all revalidators will be in the GC phas
On 23 August 2014 06:47, Ben Pfaff wrote:
> On Thu, Aug 21, 2014 at 05:41:58PM +1200, Joe Stringer wrote:
> > Signed-off-by: Joe Stringer
>
> As of this patch, there isn't an advantage to using a cmap yet, right?
>
Not yet, no. Cmaps become useful when access is spread across handler
threads as
On 23 August 2014 06:29, Ben Pfaff wrote:
> On Thu, Aug 21, 2014 at 05:41:57PM +1200, Joe Stringer wrote:
> > Signed-off-by: Joe Stringer
>
> My reading of the code is that this is redundant because
> dpif_operate() always fills in the flow.
>
Right, this is needed in a later patch. I'll look a
On 23 August 2014 10:47, Ben Pfaff wrote:
> OpenFlow packet and byte counters have always been something of an
> approximation in Open vSwitch. First, they are updated only periodically.
> Second, they can be misattributed because statistics collection does a
> retranslation and gives the statis
On 23 August 2014 10:47, Ben Pfaff wrote:
> Both existing callers calculated 'may_learn' as 'stats->n_packets > 0', so
> it was redundant. Because xlate_push_stats() is now entirely a no-op if
> 'stats->n_packets' is 0, we can now delete the tests entirely from the
> cases that previously only r
On 23 August 2014 10:47, Ben Pfaff wrote:
> xlate_push_stats() mostly does nothing if 'stats->n_packets' is 0. This
> commit allows it to skip more complicated internal logic in that case.
>
> The one case I see in which xlate_push_stats() does do something if
> 'stats->n_packets' is 0 is in the
On 08/24/2014 07:24 PM, Scott Feldman wrote:
On Aug 24, 2014, at 8:15 AM, Jamal Hadi Salim wrote:
On 08/24/14 07:12, Thomas Graf wrote:
On 08/23/14 at 09:53pm, Jamal Hadi Salim wrote:
I get what you are saying but I don't see that to be the case here. I
don't see how this series proposes
On 23 August 2014 10:47, Ben Pfaff wrote:
> MAC learning, like flow entry learning via the "learn" action, should only
> happen if a packet was actually received.
>
> Signed-off-by: Ben Pfaff
Acked-by: Joe Stringer
___
dev mailing list
dev@openvswit
On Aug 24, 2014, at 8:15 AM, Jamal Hadi Salim wrote:
> On 08/24/14 07:12, Thomas Graf wrote:
>> On 08/23/14 at 09:53pm, Jamal Hadi Salim wrote:
>
>>
>> I get what you are saying but I don't see that to be the case here. I
>> don't see how this series proposes the OVS case as *the* interface.
>
On Thu, Aug 21, 2014 at 12:24 PM, Lori Jakab wrote:
> On 8/6/14 4:37 AM, Jesse Gross wrote:
>> Besides the fact that it would be nice to unify things, I'm not sure
>> that it is actually correct to pull off VLAN, MPLS, etc. tags that we
>> don't understand. Presumably, these are being used to crea
On Thu, Aug 21, 2014 at 12:25 PM, Lorand Jakab wrote:
> struct ovs_skb_cb is full on kernels < 3.11 due to compatibility code.
> This patch removes the 'flow' member in order to make room for data
> needed by layer 3 flow/port support that will be added in an upcoming
> patch. The 'flow' memeber
On 08/24/14 07:12, Thomas Graf wrote:
On 08/23/14 at 09:53pm, Jamal Hadi Salim wrote:
I get what you are saying but I don't see that to be the case here. I
don't see how this series proposes the OVS case as *the* interface.
The focus of the patches is on offloading flows (uses the
ovs or sh
On 08/21/14 at 06:18pm, Jiri Pirko wrote:
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 39294b9..8b5d14c 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -49,6 +49,8 @@
>
> #include
> #include
> +#include
> +
> #include
>
> s
On 08/23/14 at 10:09am, John Fastabend wrote:
> Right. I think this is basically what Jiri and I discussed when he
> originally posted the series. For my use cases this is one of the
> more interesting pieces. If no one else is looking at it I can try
> it on some of the already existing open sourc
On 08/23/14 at 09:53pm, Jamal Hadi Salim wrote:
> On 08/22/14 18:53, Scott Feldman wrote:
>
> Ok, Scott - now i have looked at the patches on the plane and i am
> still not convinced ;->
>
> >The intent is to use openvswitch.ko’s struct sw_flow to program hardware via
> >the
> >ndo_swdev_flow_*
16 matches
Mail list logo
