On Mon, Apr 23, 2012 at 09:40:57PM -0700, Stephen Hemminger wrote:
>
>
> - Original Message -
> > On Mon, Apr 23, 2012 at 03:59:24PM -0700, Jesse Gross wrote:
> > > On Mon, Apr 23, 2012 at 3:32 PM, Simon Horman
> > > wrote:
> > > > On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wr
On Tue, Apr 24, 2012 at 10:32:55AM +0900, Simon Horman wrote:
> Add oxm_name and oxm_header elements to struct mf_field
> and populate those entries for fields that are present
> in both NXM and the OXM basic class.
>
> This implementation was suggested by Ben Pfaff.
>
> This does not address any
- Original Message -
> On Mon, Apr 23, 2012 at 03:59:24PM -0700, Jesse Gross wrote:
> > On Mon, Apr 23, 2012 at 3:32 PM, Simon Horman
> > wrote:
> > > On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote:
> > >> On Mon, Apr 23, 2012 at 2:08 PM, David Miller
> > >> wrote:
> > >> >
On Mon, Apr 23, 2012 at 03:59:24PM -0700, Jesse Gross wrote:
> On Mon, Apr 23, 2012 at 3:32 PM, Simon Horman wrote:
> > On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote:
> >> On Mon, Apr 23, 2012 at 2:08 PM, David Miller wrote:
> >> > From: Jesse Gross
> >> > Date: Mon, 23 Apr 2012 13
For future proofing I set if_cfg to NULL after free()ing it btw.
Ethan
> Yep it doesn't re-use it. I'll push it in a second, thanks for the
> thorough review.
>
> Ethan
>
> On Mon, Apr 23, 2012 at 18:45, Ben Pfaff wrote:
>> On Mon, Apr 23, 2012 at 01:45:24AM -0700, Ethan Jackson wrote:
>>> > Th
Yep it doesn't re-use it. I'll push it in a second, thanks for the
thorough review.
Ethan
On Mon, Apr 23, 2012 at 18:45, Ben Pfaff wrote:
> On Mon, Apr 23, 2012 at 01:45:24AM -0700, Ethan Jackson wrote:
>> > This looks more or less good-to-go to me. Thank you!
>> >
>> > (How much have you test
On Mon, Apr 23, 2012 at 01:45:24AM -0700, Ethan Jackson wrote:
> > This looks more or less good-to-go to me. Â Thank you!
> >
> > (How much have you tested it? Â What kinds of tests did you do?)
>
> I mostly did basic functional testing. Created a bunch of ports, destroyed
> them. Created bridge
Add oxm_name and oxm_header elements to struct mf_field
and populate those entries for fields that are present
in both NXM and the OXM basic class.
This implementation was suggested by Ben Pfaff.
This does not address any possible differences in the NXM and
OXM basic class fields, for instance di
These oxm_type definitions values will may be used
when parsing serialising OXM TLVs.
Signed-off-by: Simon Horman
---
v2
* As suggested by Ben Pfaff
- Drop BASIC from macro names
- Fix use of undefined macro / defining of unused macro
---
include/openflow/openflow-1.2.h | 58
Hi,
the two patches that comprise this series add oxm_field definitions to
Open vSwtich which may be used as a basis for an implementation of OXM.
The code is based heavily on the existing NXM implementation which makes
use of the same format with different field and TLV values.
OXM is the match
On Fri, Apr 20, 2012 at 08:37:45AM -0700, Ben Pfaff wrote:
> On Fri, Apr 20, 2012 at 09:24:02AM +0900, Simon Horman wrote:
> > definitions to Open vSwtich which may be used as a basis for an
> > implementation of OXM.
> >
> > The code is based heavily on the existing NXM implementation which makes
On Mon, Apr 23, 2012 at 08:34:45AM +0900, Simon Horman wrote:
> On Fri, Apr 20, 2012 at 08:36:57AM -0700, Ben Pfaff wrote:
> > On Fri, Apr 20, 2012 at 09:24:05AM +0900, Simon Horman wrote:
> > > This may be used in a similar way to nxm_mf_fields
> > > to handle parsing and serialisation of OXM TLVs
> This looks more or less good-to-go to me. Â Thank you!
>
> (How much have you tested it? Â What kinds of tests did you do?)
I mostly did basic functional testing. Created a bunch of ports, destroyed
them. Created bridges named for ports on other bridges. All the testing I did
used valgrind to
On Sun, Apr 22, 2012 at 11:45:12PM -0700, Ethan Jackson wrote:
> The existing bridge_reconfigure() implementation is suboptimal.
> When adding lots of new ports, on every pass through the run loop
> it allocates a bunch of "struct iface"s and "struct port"s, only to
> destroy them when out of time.
On Mon, Apr 23, 2012 at 3:32 PM, Simon Horman wrote:
> On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote:
>> On Mon, Apr 23, 2012 at 2:08 PM, David Miller wrote:
>> > From: Jesse Gross
>> > Date: Mon, 23 Apr 2012 13:53:42 -0700
>> >
>> >> On Mon, Apr 23, 2012 at 1:13 PM, David Miller
> It looks like your incremental removes the behavior but not the
> comment.
Oops, fixed.
Ethan
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Mon, Apr 23, 2012 at 03:33:26PM -0700, Ethan Jackson wrote:
> > Questions
> > -
> >
> > bridge_reconfigure_ofp() has the following comment:
> > /* Do any work needed to complete configuration. Don't consider ourselves
> > * done unless no work was needed in this iteration. This gu
Here's an incremental.
---
vswitchd/bridge.c | 382 +
1 file changed, 177 insertions(+), 205 deletions(-)
diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index d7a9e88..d0a0300 100644
--- a/vswitchd/bridge.c
+++ b/vswitchd/bridge.c
@@ -62,1
The existing bridge_reconfigure() implementation is suboptimal.
When adding lots of new ports, on every pass through the run loop
it allocates a bunch of "struct iface"s and "struct port"s, only to
destroy them when out of time. Additionally, when there are errors
adding or deleting ports, it can
> Questions
> -
>
> bridge_reconfigure_ofp() has the following comment:
> /* Do any work needed to complete configuration. Don't consider ourselves
> * done unless no work was needed in this iteration. This guarantees that
> * ofproto_run() has a chance to respond to newly added p
On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote:
> On Mon, Apr 23, 2012 at 2:08 PM, David Miller wrote:
> > From: Jesse Gross
> > Date: Mon, 23 Apr 2012 13:53:42 -0700
> >
> >> On Mon, Apr 23, 2012 at 1:13 PM, David Miller wrote:
> >>> From: Jesse Gross
> >>> Date: Mon, 23 Apr 2012
On Mon, Apr 23, 2012 at 2:08 PM, David Miller wrote:
> From: Jesse Gross
> Date: Mon, 23 Apr 2012 13:53:42 -0700
>
>> On Mon, Apr 23, 2012 at 1:13 PM, David Miller wrote:
>>> From: Jesse Gross
>>> Date: Mon, 23 Apr 2012 13:08:49 -0700
>>>
Assuming that the TCP stack generates large TSO fra
On Sun, Apr 22, 2012 at 10:10:35AM -0700, Justin Pettit wrote:
> This is great, Ben. Just a few minor things:
>
> > +Out-of-band control has the following benefits:
> > +
> > +- Simplicity: Out-of-band control slightly simplifies the switch
> > + implementation.
> > +
> > +- Reliabil
Thanks, I pushed both of these to master.
On Mon, Apr 23, 2012 at 11:08:11AM -0700, Ethan Jackson wrote:
> Looks good, thanks.
>
> Ethan
>
> On Mon, Apr 23, 2012 at 10:08, Ben Pfaff wrote:
> > This was causing "check-valgrind" to sometimes fail in this test.
> >
> > Signed-off-by: Ben Pfaff
>
From: Jesse Gross
Date: Mon, 23 Apr 2012 13:53:42 -0700
> On Mon, Apr 23, 2012 at 1:13 PM, David Miller wrote:
>> From: Jesse Gross
>> Date: Mon, 23 Apr 2012 13:08:49 -0700
>>
>>> Assuming that the TCP stack generates large TSO frames on transmit
>>> (which could be the local stack; something s
Pushed to master, branch-1.[23456].
On Mon, Apr 23, 2012 at 10:34:02AM -0700, Justin Pettit wrote:
> Looks good to me. Thanks.
>
> --Justin
>
>
> On Apr 23, 2012, at 9:16 AM, Ben Pfaff wrote:
>
> > update_port() can delete the port for which it is called, if the underlying
> > network device
On Mon, Apr 23, 2012 at 1:13 PM, David Miller wrote:
> From: Jesse Gross
> Date: Mon, 23 Apr 2012 13:08:49 -0700
>
>> Assuming that the TCP stack generates large TSO frames on transmit
>> (which could be the local stack; something sent by a VM; or packets
>> received, coalesced by GRO and then en
[adding ovs-dev]
On Mon, Apr 23, 2012 at 11:07:28AM -0700, Ethan Jackson wrote:
> I'm doing 200 ports in a single transaction and seeing quite a bit of
> "definitely lost" here's my valgrind output:
Can you try it again with this patch? Thanks.
--8<--cut here---
From: Jesse Gross
Date: Mon, 23 Apr 2012 13:08:49 -0700
> Assuming that the TCP stack generates large TSO frames on transmit
> (which could be the local stack; something sent by a VM; or packets
> received, coalesced by GRO and then encapsulated by STT) then you can
> just prepend the STT header
On Sun, Apr 22, 2012 at 02:22:48PM -0700, Ethan Jackson wrote:
> The existing bridge_reconfigure() implementation is sub-optimal.
> When adding lots of new ports, on every pass through the run loop
> it allocates a bunch of "struct iface"s and "struct port"s, only to
> destroy them when out of time
On Mon, Apr 23, 2012 at 12:19 PM, Stephen Hemminger
wrote:
> On Mon, 23 Apr 2012 15:15:33 -0400 (EDT)
> David Miller wrote:
>
>> From: Simon Horman
>> Date: Mon, 23 Apr 2012 17:30:08 +0900
>>
>> > I'm pretty sure the patch I posted added encap_rcv to tcp_sock.
>> > Am I missing the point?
>>
>>
On Mon, 23 Apr 2012 15:15:33 -0400 (EDT)
David Miller wrote:
> From: Simon Horman
> Date: Mon, 23 Apr 2012 17:30:08 +0900
>
> > I'm pretty sure the patch I posted added encap_rcv to tcp_sock.
> > Am I missing the point?
>
> It did, my eyes are failing me :-)
>
> > Currently I am setting up a
From: Simon Horman
Date: Mon, 23 Apr 2012 17:30:08 +0900
> I'm pretty sure the patch I posted added encap_rcv to tcp_sock.
> Am I missing the point?
It did, my eyes are failing me :-)
> Currently I am setting up a listening socket. The Open vSwtich tunneling
> code transmits skbs and using eith
OK, great, thanks for looking into it.
On Mon, Apr 23, 2012 at 11:15:28AM -0700, Ethan Jackson wrote:
> Looking through the code, it hasn't been used since switching was
> moved from the bridge into ofproto-dpif as suspected.
>
> Ethan
>
> On Mon, Apr 23, 2012 at 11:09, Ethan Jackson wrote:
> >
Looking through the code, it hasn't been used since switching was
moved from the bridge into ofproto-dpif as suspected.
Ethan
On Mon, Apr 23, 2012 at 11:09, Ethan Jackson wrote:
> I had assumed that it's left over from when the bridge did bonding and
> learning. I'll look through the commit his
I had assumed that it's left over from when the bridge did bonding and
learning. I'll look through the commit history to verify.
Ethan
On Mon, Apr 23, 2012 at 09:18, Ben Pfaff wrote:
> This looks good but did you look back to figure out what we had been
> using this for and whether it was truly
Looks good, thanks.
Ethan
On Mon, Apr 23, 2012 at 10:08, Ben Pfaff wrote:
> With "check-valgrind" the test can take more than 10 seconds to run, so
> replacing only a single trailing digit with ? ends up with 1? which causes
> the test to fail.
>
> Signed-off-by: Ben Pfaff
> ---
> tests/ofprot
Looks good, thanks.
Ethan
On Mon, Apr 23, 2012 at 10:08, Ben Pfaff wrote:
> This was causing "check-valgrind" to sometimes fail in this test.
>
> Signed-off-by: Ben Pfaff
> ---
> tests/daemon.at | 5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/tests/daemon.at b
Looks good to me. Thanks.
--Justin
On Apr 23, 2012, at 9:16 AM, Ben Pfaff wrote:
> update_port() can delete the port for which it is called, if the underlying
> network device has been destroyed, so HMAP_FOR_EACH is unsafe in
> ofproto_run().
>
> Less obviously, update_port() can delete unrel
With "check-valgrind" the test can take more than 10 seconds to run, so
replacing only a single trailing digit with ? ends up with 1? which causes
the test to fail.
Signed-off-by: Ben Pfaff
---
tests/ofproto-dpif.at | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --gi
This was causing "check-valgrind" to sometimes fail in this test.
Signed-off-by: Ben Pfaff
---
tests/daemon.at |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/tests/daemon.at b/tests/daemon.at
index 69fff25..f188e7c 100644
--- a/tests/daemon.at
+++ b/tests/daemon.at
Ethan reported that "make check-valgrind" had a number of failures on
master. Here's a fix for a couple of them.
Ben Pfaff (2):
tests: Avoid daemon race between pidfile creation and parent
notification.
tests: Generalize 'sed' calls in MAC learning test to more than one
digit.
tests
This looks good but did you look back to figure out what we had been
using this for and whether it was truly no longer needed?
Thanks,
Ben.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
update_port() can delete the port for which it is called, if the underlying
network device has been destroyed, so HMAP_FOR_EACH is unsafe in
ofproto_run().
Less obviously, update_port() can delete unrelated ports. For example,
suppose that initially device A is port 1 and device B is port 2. If
From: Simon Horman
Date: Mon, 23 Apr 2012 14:14:02 +0900
> On Sun, Apr 22, 2012 at 11:54:42AM -0400, Jamal Hadi Salim wrote:
>> On Sun, 2012-04-22 at 08:22 -0700, Stephen Hemminger wrote:
>>
>> > STT isn't really doing TCP, it just lying and pretending to be
>> > TCP to allow TSO to work! There
45 matches
Mail list logo
