On Fri, Aug 2, 2013 at 11:36 PM, Ben Pfaff wrote:
> On Fri, Aug 02, 2013 at 10:27:14PM -0700, Andy Zhou wrote:
>> In the case of mega flow would this cause multiple subfacets within a facet
>> to be considered installed?
>>
>>
>> On Fri, Aug 2, 2013 at 10:21 PM, Ben Pfaff wrote:
>>
>> > On Fri, A
On Fri, Aug 02, 2013 at 11:24:58PM -0700, Jesse Gross wrote:
> On Fri, Aug 2, 2013 at 11:13 PM, Ben Pfaff wrote:
> > On Fri, Aug 02, 2013 at 10:57:53PM -0700, Justin Pettit wrote:
> >> The ODP library has an optimization to not set a header if the field was
> >> not changed, regardless of whether
On Fri, Aug 02, 2013 at 10:27:14PM -0700, Andy Zhou wrote:
> In the case of mega flow would this cause multiple subfacets within a facet
> to be considered installed?
>
>
> On Fri, Aug 2, 2013 at 10:21 PM, Ben Pfaff wrote:
>
> > On Fri, Aug 02, 2013 at 08:22:17PM -0700, Andy Zhou wrote:
> > > T
On Fri, Aug 2, 2013 at 11:13 PM, Ben Pfaff wrote:
> On Fri, Aug 02, 2013 at 10:57:53PM -0700, Justin Pettit wrote:
>> The ODP library has an optimization to not set a header if the field was
>> not changed, regardless of whether an action to set the field was
>> present. That library is also resp
On Fri, Aug 02, 2013 at 10:57:53PM -0700, Justin Pettit wrote:
> The ODP library has an optimization to not set a header if the field was
> not changed, regardless of whether an action to set the field was
> present. That library is also responsible for un-wildcarding fields
> that are bieng modif
On Fri, Aug 02, 2013 at 10:53:40PM -0700, Justin Pettit wrote:
> > In the case where we do emit a "set" action, we un-wildcard not just the
> > single field but all the fields that have to be set in the datapath in
> > one go. Is that necessary here? My initial thought is "no" but I want
> > to m
The ODP library has an optimization to not set a header if the field was
not changed, regardless of whether an action to set the field was
present. That library is also responsible for un-wildcarding fields
that are bieng modified. This leads to a problem where a packet matches
a flow that update
On Aug 2, 2013, at 10:08 PM, Ben Pfaff wrote:
> I think that OFPACT_STRIP_VLAN and OFPACT_PUSH_VLAN also need updated
> treatment.
Fixed.
> Does nxm_execute_reg_move() need to un-wildcard the dest field too?
> Seems so. How about nxm_execute_stack_pop()?
Agreed.
> How about compose_mpls_pus
In the case of mega flow would this cause multiple subfacets within a facet
to be considered installed?
On Fri, Aug 2, 2013 at 10:21 PM, Ben Pfaff wrote:
> On Fri, Aug 02, 2013 at 08:22:17PM -0700, Andy Zhou wrote:
> > This patch prevents the same subfacet from trying to install the kernel
> >
On Fri, Aug 02, 2013 at 10:14:02PM -0700, Ethan Jackson wrote:
> > I thought we introduced this to make debugging easier in real problem
> > situations. It would be pretty easy to make thread safe with an
> > atomic_bool.
>
> I'm more worried about accessing the ofproto_trace() function from
> ou
On Fri, Aug 02, 2013 at 08:22:17PM -0700, Andy Zhou wrote:
> This patch prevents the same subfacet from trying to install the kernel
> flow more than once.
>
> This is how a kernel flow can become unexpected to the user space.
> When a incoming packet did not match any flow in the kernel, it
> wo
> I thought we introduced this to make debugging easier in real problem
> situations. It would be pretty easy to make thread safe with an
> atomic_bool.
I'm more worried about accessing the ofproto_trace() function from
outside of ofproto_dpif. I'm trying to keep the interface in
ofproto-dpif.h
On Fri, Aug 02, 2013 at 09:33:27PM -0700, Justin Pettit wrote:
> The ODP library has an optimization to not set a header if the field was
> not changed, regardless of whether an action to set the field was
> present. That library is also responsible for un-wildcarding fields
> that are bieng modif
The ODP library has an optimization to not set a header if the field was
not changed, regardless of whether an action to set the field was
present. That library is also responsible for un-wildcarding fields
that are bieng modified. This leads to a problem where a packet matches
a flow that update
This patch prevents the same subfacet from trying to install the kernel
flow more than once.
This is how a kernel flow can become unexpected to the user space.
When a incoming packet did not match any flow in the kernel, it
would be sent up to the user space. A subfacet would be created and
a co
Thanks, I applied it to master.
On Fri, Aug 02, 2013 at 06:02:30PM -0700, Alex Wang wrote:
> Thanks Ben,
>
> It looks good to me,
>
>
> On Fri, Aug 2, 2013 at 5:33 PM, Ben Pfaff wrote:
>
> > Until now, the async append interface has required async_append_enable()
> > to be called while the pr
On Fri, Aug 02, 2013 at 06:31:38PM -0700, Ethan Jackson wrote:
> This code is not particularly important and will be inconvenient to
> make thread safe.
>
> Signed-off-by: Ethan Jackson
I thought we introduced this to make debugging easier in real problem
situations. It would be pretty easy to
On Fri, Aug 02, 2013 at 06:31:37PM -0700, Ethan Jackson wrote:
> I had intended to fold this into a previous patch.
>
> Signed-off-by: Ethan Jackson
Acked-by: Ben Pfaff
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/d
This code is not particularly important and will be inconvenient to
make thread safe.
Signed-off-by: Ethan Jackson
---
ofproto/ofproto-dpif-xlate.c | 27 +--
ofproto/ofproto-dpif.c |4 +++-
ofproto/ofproto-dpif.h |3 ---
3 files changed, 4 insertions
I had intended to fold this into a previous patch.
Signed-off-by: Ethan Jackson
---
ofproto/ofproto-dpif-xlate.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index bba4355..f7aa01d 10
> ovs_mutex_lock(&ofproto->flow_mod_mutex);
> if (ofproto->n_flow_mods) {
> flow_mods = ofproto->flow_mods;
> list_moved(&flow_mods);
> list_init(&ofproto->flow_mods);
> ofproto->n_flow_mods--;
> } else {
> list_init(&flow_mods);
> }
> ovs
Thanks Ben,
It looks good to me,
On Fri, Aug 2, 2013 at 5:33 PM, Ben Pfaff wrote:
> Until now, the async append interface has required async_append_enable()
> to be called while the process was still single-threaded, with the
> rationale being that async_append_enable() could race with
> async
On Fri, Aug 02, 2013 at 05:50:46PM -0700, Ethan Jackson wrote:
> Thanks for the review, here's a new version.
>
> Ethan
That's what I had in mind, thanks.
Acked-by: Ben Pfaff
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/list
Thanks for the review, here's a new version.
Ethan
---
ofproto/ofproto-dpif-xlate.c | 79 +++-
ofproto/ofproto-dpif-xlate.h |5 +-
ofproto/ofproto-dpif.c | 104 +++---
ofproto/ofproto-dpif.h |2 -
4 files chan
Yes, I'm doing that.
On Fri, Aug 2, 2013 at 5:44 PM, Ethan Jackson wrote:
> The commit message sounds good to me. Alex, would you be willing to
> review it?
>
> Ethan
>
> On Fri, Aug 2, 2013 at 5:34 PM, Ben Pfaff wrote:
> > I sent out a counterproposal:
> > http://openvswitch.org/pipe
The commit message sounds good to me. Alex, would you be willing to review it?
Ethan
On Fri, Aug 2, 2013 at 5:34 PM, Ben Pfaff wrote:
> I sent out a counterproposal:
> http://openvswitch.org/pipermail/dev/2013-August/030288.html
> Please review it, if you have time.
>
> Is there a bug #
Until now, the async append interface has required async_append_enable()
to be called while the process was still single-threaded, with the
rationale being that async_append_enable() could race with
async_append_write() on some existing async_append object. This was a
difficult problem when the as
I sent out a counterproposal:
http://openvswitch.org/pipermail/dev/2013-August/030288.html
Please review it, if you have time.
Is there a bug # for this? If so, I will add it to the commit message.
On Fri, Aug 02, 2013 at 04:47:39PM -0700, Alex Wang wrote:
> No problem, I'm also not sure
No problem, I'm also not sure if that is the right place or way.
Thanks,
Alex Wang,
On Fri, Aug 2, 2013 at 4:45 PM, Ben Pfaff wrote:
> On Fri, Aug 02, 2013 at 03:47:45PM -0700, Alex Wang wrote:
> > Commit a5fb0e29a9c56 (vlog: Use async I/O.) invokes the function
> > async_append_enable() in br
On Fri, Aug 02, 2013 at 03:47:45PM -0700, Alex Wang wrote:
> Commit a5fb0e29a9c56 (vlog: Use async I/O.) invokes the function
> async_append_enable() in bridge_run(). This may cause the abortion
> of ovs-vswitchd since async_append_enable() must be invoked while
> single-threaded. And it is possibl
On Fri, Aug 02, 2013 at 04:12:36PM -0700, Paul Ingram wrote:
> The remote opstate for a CFM interface is presumed to be up unless a CCM is
> received which signals opstate down. This means than an interface configured
> for CFM demand mode may incorrectly appear to be opstate up if it has not
> rec
The remote opstate for a CFM interface is presumed to be up unless a CCM is
received which signals opstate down. This means than an interface configured
for CFM demand mode may incorrectly appear to be opstate up if it has not
received a CCM within the last fault interval.
We should remember the l
Commit a5fb0e29a9c56 (vlog: Use async I/O.) invokes the function
async_append_enable() in bridge_run(). This may cause the abortion
of ovs-vswitchd since async_append_enable() must be invoked while
single-threaded. And it is possible that system-state.c spawns a
thread before the invocation.
This
> I think that we should keep ofoperation_get_victim() and the related
> comment in ofproto_class, because it seems completely reasonable that
> some ofproto implementation would need this information. I am surprised
> that ofproto-dpif no longer needs it.
Done, thanks for the review, I'll merge
> I am not sure whether the new call to bond_entry_reset() in
> bond_slave_register() is really necessary because tags were removed
> (bond_entry_reset() doesn't cause revalidation, for example), or whether
> it is a bug fix or, arguably, a refinement of existing behavior to
> ensure that all traff
Thanks for the review. Based on a comment on a future patch I changed
this to always set REV_MAC_LEARNING if mac_learning_run() returns
true. I'll merge shortly.
Ethan
On Fri, Aug 2, 2013 at 8:51 AM, Ben Pfaff wrote:
> On Thu, Aug 01, 2013 at 07:08:32PM -0700, Ethan Jackson wrote:
>> This patc
Thanks for looking them over. I applied the ones that weren't
BSD-specific. I'll give Ed a few more days to look over the rest, if he
wants, since I just posted this series yesterday.
On Fri, Aug 02, 2013 at 10:16:31AM -0700, Alex Wang wrote:
> Patches 01/27 - 10/27 all look good. Thanks,
>
> A
Good Day,
My name is Richard Gardner and I am working on behalf of William Wilton Private
investors in London, United Kingdom. I would like to know if you have any
project(s) in your country, involving small or large volume of funds, for which
you seek financing and for us to facilitate.
I am
On Aug 2, 2013, at 1:38 PM, Pravin B Shelar
wrote:
> Changes are mostly related API changes in vlan, GRE
> restructuring.
>
> Signed-off-by: Pravin B Shelar
Looks good and works with this kernel. Only nit is to add FAQ
and NEWS items for this.
Acked-by: Kyle Mestery
[kmestery@km-dhcp-64-24
On Aug 2, 2013, at 1:38 PM, Pravin B Shelar
wrote:
> Changes are mostly related API changes in vlan, GRE
> restructuring.
>
> Signed-off-by: Pravin B Shelar
Testing this one now. Mental to always read all the unread
email in a list before testing and replying. :)
_
On Aug 1, 2013, at 5:21 PM, Pravin B Shelar wrote:
> Changes are mostly related API changes in vlan, GRE
> restructuring.
>
> Signed-off-by: Pravin B Shelar
Thanks Pravin, looks good and works for me. Tested on this
kernel:
[kmestery@km-dhcp-64-245 ~]$ uname -a
Linux km-dhcp-64-245.kmestery.c
Changes are mostly related API changes in vlan, GRE
restructuring.
Signed-off-by: Pravin B Shelar
---
v1-v2:
I missed __vlan_put_tag() change in v1.
---
datapath/actions.c |6 +-
datapath/datapath.c|2 +-
datapath/linux/Modu
On Thu, Aug 01, 2013 at 03:55:47PM -0700, Ethan Jackson wrote:
> Once we have multiple threads running, having each execute flow mods
> created by the learn action won't be tenable. It essentially will
> require us to make the core ofproto module thread safe, which is not
> the direction we want t
On Thu, Aug 01, 2013 at 03:55:46PM -0700, Ethan Jackson wrote:
> This will make locking easier in future patches.
>
> Signed-off-by: Ethan Jackson
We renamed 'priority' to 'skb_priority' in struct flow, it would be nice
for the naming here to reflect that.
Folding in the following incremental m
On Thu, Aug 01, 2013 at 03:55:45PM -0700, Ethan Jackson wrote:
> This patch pulls the STP xlation code into ofproto-dpif-xlate where it
> will be easier to guard.
>
> Signed-off-by: Ethan Jackson
The xlate_ofproto_set() and xlate_ofport_set() function signatures are
pretty nasty. That's mostly
On Thu, Aug 01, 2013 at 07:08:34PM -0700, Ethan Jackson wrote:
> This patch retires a venerable library whose inception dates before
> the first patch of the current repository: tags. They have served us
> well, but their time has come for the reasons listed below.
>
> 1) They don't actually help
On Thu, Aug 01, 2013 at 07:08:33PM -0700, Ethan Jackson wrote:
> This patch transitions bonding away from using tags as required by
> future patches.
>
> Signed-off-by: Ethan Jackson
I am not sure whether the new call to bond_entry_reset() in
bond_slave_register() is really necessary because tag
Patches 01/27 - 10/27 all look good. Thanks,
Alex Wang,
On Thu, Aug 1, 2013 at 2:29 PM, Ben Pfaff wrote:
> Signed-off-by: Ben Pfaff
> ---
> lib/netdev-linux.c |3 +--
> lib/netdev.c |6 ++
> 2 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/lib/netdev-linux.
On Thu, Aug 01, 2013 at 07:08:32PM -0700, Ethan Jackson wrote:
> This patch transitions mac learning away from using tags as required
> by future patches.
>
> Signed-off-by: Ethan Jackson
Good-bye, tags. I felt clever when I invented you.
Acked-by: Ben Pfaff
__
49 matches
Mail list logo
