On Fri, Aug 23, 2013 at 09:10:20AM -0700, Ben Pfaff wrote:
> On Fri, Aug 23, 2013 at 05:43:25PM +1000, Simon Horman wrote:
> > I am wondering if it is expected for the following warnings to show up
> > when functions do not always take locks.
>
> Yes, until someone reviews my patches that fix the
On Thu, Aug 22, 2013 at 3:29 AM, Viresh Kumar wrote:
> 2- local_bh_disable()
>
> This is how it is implemented:
>
> +void local_bh_disable(void)
> +{
> + migrate_disable();
> + current->softirq_nestcnt++;
> +}
> +EXPORT_SYMBOL(local_bh_disable);
>
> And here is the problem: Code curren
On Tue, Aug 20, 2013 at 2:31 PM, Pravin B Shelar wrote:
> Upstream vxlan implementation was changed according to few
> comments. Following patch brings back those changes to out
> of tree ovs module.
>
> Signed-off-by: Pravin B Shelar
A couple minor things that I noticed:
> diff --git a/datapa
On Aug 23, 2013, at 1:33 PM, Ben Pfaff wrote:
> On Fri, Aug 23, 2013 at 12:46:47PM -0700, Jarno Rajahalme wrote:
>> On Aug 23, 2013, at 11:26 AM, Ben Pfaff wrote:
>>> Looking at tnl_find() in ofproto/tunnel.c, it maintains the invariant
>>> "set to 0 if and only if we set _flow to true", excep
On Fri, Aug 23, 2013 at 2:56 AM, James Page wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Jesse
>
> On 22/08/13 20:44, Jesse Gross wrote:
>>> Fair enough - the deltas for 3.9 and 3.10 support are quite
>>> small; I
was struggling with the changes in the 3.11 kernel in the
On Aug 23, 2013, at 3:20 PM, Jesse Gross wrote:
> On Fri, Aug 23, 2013 at 12:46 PM, Jarno Rajahalme
> wrote:
>> On Aug 23, 2013, at 11:26 AM, Ben Pfaff wrote:
>>> Looking at tnl_find() in ofproto/tunnel.c, it maintains the invariant
>>> "set to 0 if and only if we set _flow to true", except
On Fri, Aug 23, 2013 at 1:33 PM, Ben Pfaff wrote:
> On Fri, Aug 23, 2013 at 12:46:47PM -0700, Jarno Rajahalme wrote:
>> On Aug 23, 2013, at 11:26 AM, Ben Pfaff wrote:
>> > Looking at tnl_find() in ofproto/tunnel.c, it maintains the invariant
>> > "set to 0 if and only if we set _flow to true", e
On Fri, Aug 23, 2013 at 12:46 PM, Jarno Rajahalme wrote:
> On Aug 23, 2013, at 11:26 AM, Ben Pfaff wrote:
>> Looking at tnl_find() in ofproto/tunnel.c, it maintains the invariant
>> "set to 0 if and only if we set _flow to true", except
>> for = ip_src. Is that a bug?
>>
>
> No, it is not a bu
On Fri, Aug 23, 2013 at 12:46:47PM -0700, Jarno Rajahalme wrote:
> On Aug 23, 2013, at 11:26 AM, Ben Pfaff wrote:
> > Looking at tnl_find() in ofproto/tunnel.c, it maintains the invariant
> > "set to 0 if and only if we set _flow to true", except
> > for = ip_src. Is that a bug?
> >
>
> No, i
On Aug 23, 2013, at 11:26 AM, Ben Pfaff wrote:
> Looking at tnl_find() in ofproto/tunnel.c, it maintains the invariant
> "set to 0 if and only if we set _flow to true", except
> for = ip_src. Is that a bug?
>
No, it is not a bug. Tunnel config allows you to leave local address unset
(=0), al
On Fri, Aug 23, 2013 at 10:40:50AM -0700, Gurucharan Shetty wrote:
> On Thu, Aug 22, 2013 at 11:19 AM, Ben Pfaff wrote:
>
> > Fixes the following sparse warnings introduced by commit 7c35397c84d
> > (ofproto: Start ofport allocation from the previous max after restart.)
> >
> > ofproto.c:2106:58:
On Thu, Aug 22, 2013 at 02:24:18PM -0700, Alex Wang wrote:
> The declaration of 'get_max_ports()' to return odp_port_t adds
> unwanted complexity to coding. This commit changes it back to
> return uint32_t type.
>
> Signed-off-by: Alex Wang
Both applied, thank you!
_
Looking at tnl_find() in ofproto/tunnel.c, it maintains the invariant
"set to 0 if and only if we set _flow to true", except
for = ip_src. Is that a bug?
Thanks,
Ben.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/de
On Thu, Aug 22, 2013 at 02:09:57PM -0700, Jarno Rajahalme wrote:
>
> On Aug 22, 2013, at 1:59 PM, pritesh wrote:
>
> > Signed-off-by: pritesh
> > ---
> > ofproto/tunnel.c |1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/ofproto/tunnel.c b/ofproto/tunnel.c
> > index 0ba0066..2023
On Thu, Aug 22, 2013 at 01:40:04PM -0700, Jarno Rajahalme wrote:
>
> On Aug 22, 2013, at 11:17 AM, Ben Pfaff wrote:
>
> > OFPERR_OFPBAC_BAD_ARGUMENT is not as specific as the errors provided by
> > OpenFlow 1.2 and later.
> >
> > Some of these errors needed Nicira extension numbers for use with
On Thu, Aug 22, 2013 at 04:51:15PM -0700, Jean Tourrilhes wrote:
> On Thu, Aug 22, 2013 at 11:17:12AM -0700, Ben Pfaff wrote:
> >
> > Some of these errors needed Nicira extension numbers for use with OpenFlow
> > 1.0 and 1.1, so this commit also adds those.
>
> That's the thing I was not su
Thank you for the reviews. I removed the blank line and will apply
these in a minute.
On Fri, Aug 23, 2013 at 10:00:17AM -0700, Jarno Rajahalme wrote:
> Good, except for that one extra blank line?
>
> Acked-by: Jarno Rajahalme
>
> On Aug 21, 2013, at 1:01 PM, Ben Pfaff wrote:
>
> > I get a b
On Thu, Aug 22, 2013 at 04:01:41PM -0700, Jarno Rajahalme wrote:
> Signed-off-by: Jarno Rajahalme
Applied, thanks.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Thu, Aug 22, 2013 at 03:51:39PM -0700, Jarno Rajahalme wrote:
> There were two calls to subfacet_create(), which is redundant. The first
> one seemed the one to remove, as there is a subsequent test on the facet's
> subfacet list being empty, which is never true after a call to
> subfacet_creat
If we allow oversize datapath actions to make it out of translation, then
we will assert-fail later when we try to put those actions into a Netlink
attribute.
Bug #19277.
Reported-by: Paul ingram
Signed-off-by: Ben Pfaff
---
I'm not at all sure that this is the best way to do this.
lib/netlink
Thanks, I was wondering about that.
On Thu, Aug 22, 2013 at 04:21:56PM -0700, Jarno Rajahalme wrote:
> Please disregard the "1/3" in subject, there is no later parts for
> this patch "series"?
>
>Jarno
>
> On Aug 22, 2013, at 4:01 PM, Jarno Rajahalme wrote:
>
> > Signed-off-by: Jarno Rajah
On Thu, Aug 22, 2013 at 11:19 AM, Ben Pfaff wrote:
> Fixes the following sparse warnings introduced by commit 7c35397c84d
> (ofproto: Start ofport allocation from the previous max after restart.)
>
> ofproto.c:2106:58: warning: restricted ofp_port_t degrades to integer
> ofproto.c:2107:40: warnin
On Fri, Aug 23, 2013 at 12:05:44AM -0700, Ethan Jackson wrote:
> "actions=resubmit:1, resubmit:2, output:1"
>
> I don't totally get this. If this is your only flow, won't you fall
> into an infinite loop and hit the MAX_RESUBMIT depth?
Yes. Before this patch, you'd then pop up one level and hi
Good, except for that one extra blank line…
Acked-by: Jarno Rajahalme
On Aug 21, 2013, at 1:01 PM, Ben Pfaff wrote:
> I get a bunch of thread-safety warnings with the latest Clang without this
> patch, because Clang is smart enough to see locking and unlocking but not
> smart enough to figure
This works.
Acked-by: Jarno Rajahalme
On Aug 21, 2013, at 1:01 PM, Ben Pfaff wrote:
> New Clang versions raise warnings about the incorrect old annotation.
>
> I first noticed these warnings with Clang 1:3.4~svn188890-1~exp1.
> I previously used version 1:3.4~svn187484-1~exp1.
>
> Signed-off
On Fri, Aug 23, 2013 at 05:43:25PM +1000, Simon Horman wrote:
> I am wondering if it is expected for the following warnings to show up
> when functions do not always take locks.
Yes, until someone reviews my patches that fix the Clang annotations:
http://patchwork.openvswitch.org/patch/106
Title: Document sans nom
Annicette Coulibaly
pense que cet article pourrait vous intéresser
Hei min kjære, Vennligst Jeg trenger din hjelp
Hei min kjære, Vennligst Jeg trenger din hjelp
Vennligst tillate meg å presentere meg selv, jeg er
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Jesse
On 22/08/13 20:44, Jesse Gross wrote:
>> Fair enough - the deltas for 3.9 and 3.10 support are quite
>> small; I
>>> was struggling with the changes in the 3.11 kernel in the way
>>> gre is handled; I think the gre module in the kernel is
>
Hi Ethan,
I am wondering if it is expected for the following warnings to show up
when functions do not always take locks.
The reason that I as is that I am planning to use a similar scheme
in conjunction with a revised version of the recirculation code that
I am working on to take into account yo
"actions=resubmit:1, resubmit:2, output:1"
I don't totally get this. If this is your only flow, won't you fall
into an infinite loop and hit the MAX_RESUBMIT depth?
When you say it exhausts memory, are you talking about odp_actions?
If so, why not simply limit the size of the odp_actions direct
30 matches
Mail list logo
