Hello,
I am experimenting with the group "select" feature, for which I have modified
"group_best_live_bucket()" function in "ofproto-dpif-xlate.c" to stochastically
choose a bucket based on bucket weights (changes shown below).
My understanding was that every time a packet arrives at the s
On Tue, Feb 18, 2014 at 7:31 AM, Mohammad Ali Salahuddin
wrote:
> Then, I started to a log a message whenever this function was invoked. To my
> surprise, the logging revealed that this function is not being invoked for
> every packet.
>
> Is this the expected behavior? Am I missing something?
Op
Is there a way to turn off this caching?
Thanks!
> Date: Tue, 18 Feb 2014 08:32:54 -0800
> Subject: Re: xlate_select_group() not being invoked for every packet
> From: b...@nicira.com
> To: saeen...@hotmail.com
> CC: dev@openvswitch.org
>
> On Tue, Feb 18, 2014 at 7:31 AM, Mohammad Ali Salahuddin
You can add
ctx->xout->slow |= SLOW_CONTROLLER;
to xlate_select_group().
On Tue, Feb 18, 2014 at 09:46:03AM -0700, Mohammad Ali Salahuddin wrote:
> Is there a way to turn off this caching?
> Thanks!
>
> > Date: Tue, 18 Feb 2014 08:32:54 -0800
> > Subject: Re: xlate_select_group() not being in
This wording was in ofproto.c, but missing from ofproto-provider.h.
Signed-off-by: Joe Stringer
---
ofproto/ofproto-provider.h |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ofproto/ofproto-provider.h b/ofproto/ofproto-provider.h
index 08a8ac1..8172dd3 100644
--- a/o
Previously, we would prefer to get the type for an ofport from the
corresponding dpif_port, rather than from the netdev. This would cause
lookups for ports of "tap" type to report that they are of type
"system".
Each time we see a port of the wrong type in bridge_reconfigure(), we
remove it and ad
Pushed to master,
Jarno
On Feb 16, 2014, at 12:02 AM, Jesse Gross wrote:
> On Tue, Feb 11, 2014 at 4:07 PM, Jarno Rajahalme
> wrote:
>> The 5-tuple optimization becomes unnecessary with a later per-NUMA
>> node stats patch. Remove it first to make the changes easier to
>> grasp.
>>
>> Sig
Thanks for the reviews. I fixed the comments and the sparse warning and pushed
to master.
Jarno
On Feb 16, 2014, at 12:05 AM, Jesse Gross wrote:
> On Fri, Feb 14, 2014 at 4:15 PM, Pravin Shelar wrote:
>> I got following sparse warning.
>>
>> /home/pravin/ovs/w6/datapath/linux/flow_table.c:
Thanks a lot Han for the close review ;D
Please see my comments inline.
On Sat, Feb 15, 2014 at 8:44 AM, Han Zhou wrote:
> > -add_channel(struct dpif_linux *dpif, odp_port_t port_no, struct nl_sock
> *sock)
> > +add_vport_channels(struct dpif_linux *dpif, odp_port_t port_no,
> > +
On Feb 16, 2014, at 5:11 PM, Simon Horman wrote:
> On Mon, Feb 17, 2014 at 10:06:55AM +0900, Simon Horman wrote:
>> Remove the restriction that pop MPLS to an ethtype is
>> considered inconsistent.
>>
>> As it happens this is allowed for OpenFlow 1.0, and thus
>> the tests in the Open vSwtich t
On 14 February 2014 11:17, Jarno Rajahalme wrote:
>
> Access to a shared variable that may change concurrently without any sort
> of synchronization should be atomic to protect against "tearing", where the
> reader gets a mixture of the old and new versions of the variable. This
> could happen for
Signed-off-by: Joe Stringer
---
v3: Use 'unsigned' instead of 'long long int' for ofproto_max_idle.
v2: Don't cache the max_idle in 'struct udpif'.
Extend range of valid values to 100-3.
---
ofproto/ofproto-dpif-upcall.c |5 ++---
ofproto/ofproto-provider.h|4
ofproto/of
It's slightly smaller/faster for some architectures.
Signed-off-by: Joe Perches
---
net/openvswitch/actions.c | 4 ++--
net/openvswitch/flow.c | 16
net/openvswitch/flow_netlink.c | 12 ++--
3 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/n
Adding ctx->xout->slow |= SLOW_CONTROLLER; to xlate_select_group() resolved my
issue. Thank you *very* much.
So, does this statement completely shut off caching? How does it work under the
hood? I am curious because intuitively "SLOW_CONTROLLER" would mean more
caching should be performed at th
When creating tap ports in dpif-linux, the "tap" type is treated the
same as "system", and the type is discarded. When dumping datapath
port types, this would cause "tap" type to be reported as a "system"
type.
Each time we see a port of the wrong type in bridge_reconfigure(), we
remove it and add
If ovs-vsctl has to wait for ovs-vswitchd to reconfigure itself
according to the new database, then sometimes ovs-vsctl could
end up stuck in the event loop if OVSDB connection was dropped
while ovs-vsctl was still running.
This patch fixes this problem by letting ovs-vsctl to reconnect
to the OVS
It tells the caching code that every packet in the flow in question must
go to the userspace "slow path". The "controller" keyword ordinarily
would mean that packets have to go to the controller, but that reason is
only there for humans to read in "ovs-dpctl" flow dumps and doesn't
actually cause
Acked-by: Alex Wang
Ethan,
Could you have a look of this patch? Do you think get_vport_type() is the
right place?
Thanks,
Alex Wang,
On Tue, Feb 18, 2014 at 2:26 PM, Joe Stringer wrote:
> When creating tap ports in dpif-linux, the "tap" type is treated the
> same as "system", and the type
From: Joe Perches
Date: Tue, 18 Feb 2014 11:15:45 -0800
> It's slightly smaller/faster for some architectures.
>
> Signed-off-by: Joe Perches
I'll let Jesse take this via his tree, thanks Joe.
___
dev mailing list
dev@openvswitch.org
http://openvswit
I asked Ethan and he suggested that Ben might have a better idea.
Ben, is this approach fine? I'm not entirely clear on what the relationship
is between netdev types and datapath port types.
On 18 February 2014 14:45, Alex Wang wrote:
> Acked-by: Alex Wang
>
> Ethan,
>
> Could you have a look
Hi Alex,
On Tue, 2014-02-18 at 10:26 -0800, Alex Wang wrote:
> Thanks a lot Han for the close review ;D
My pleasure :)
>
> In this function, you separated vport transaction for creating
> vports
> and setting channel pids to kernel. But it could lead to
>
Hey Han,
Again, thanks for your comments, ;D
On Tue, Feb 18, 2014 at 10:46 PM, Zhou, Han wrote:
> > I think it is okay that we miss the upcalls for a short period.
> >
> >
> > The way current ovs calls 'port_add()' is that ODPP_NONE is given for
> > '*port_nop'.
> > And the datapath will dense
22 matches
Mail list logo
