[ Reply to add subject,
I apologise for that not being there the first time around ]
On Thu, Apr 19, 2012 at 01:50:02PM +0900, Simon Horman wrote:
> This series contains a prototype implementation of STT for Open vSwitch.
>
> This series consists of two patches:
>
> * datapath: tunneling: Push
This hook is based on a hook of the same name provided by UDP. It provides
a way for to receive packets that have a TCP header and treat them in some
alternate way.
It is intended to be used by an implementation of the STT tunneling
protocol within Open vSwtich's datapath. A prototype of such an
This is a not yet well exercised implementation of STT intended for review,
I am sure there are numerous areas that need improvement.
In particular:
- The transmit path's generation of partial checksums needs to be tested
- The VLAN stripping code needs to be excercised
- The code needs to be exer
This allows tunneling protocols to set the VLAN TCI to a non-zero
value and will be used by the implementation of STT.
Implementation suggested by Jesse Gross
Cc: Jesse Gross
Signed-off-by: Simon Horman
---
datapath/tunnel.c |1 -
datapath/vport-capwap.c |1 +
datapath/vport-gre.
This series contains a prototype implementation of STT for Open vSwitch.
This series consists of two patches:
* datapath: tunneling: Push vlan_set_tci() call into protocol handlers
This allows tunneling protocols to set the VLAN TCI to a non-zero
value and will be used by the implementation
I wasn't able to spot anything but quoted text here.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
> Both facet_learn() and facet_account() use 'accounted_bytes', so if
> either one of them updates it then the order in which one must call
> them is artificially forced. I thought that this was a better way.
Ah, that makes sense.
>> I think I'm just a bit confused, it may be worth expanding th
On Tue, Apr 17, 2012 at 03:46:00PM -0700, Ethan Jackson wrote:
> I'm having a bit of trouble understanding this patch.
>
> It seems to me like it continues to do accounting when removing
> facets, what it's actually doing is avoiding learning when removing
> them. I may be misinterpreting though.
On Wed, Apr 18, 2012 at 01:26:46PM -0700, Ethan Jackson wrote:
> Quite an elegant data structure. Pretty nifty.
Thanks.
> On Mon, Apr 16, 2012 at 17:19, Ben Pfaff wrote:
> > The cost of creating and initializing facets and subfacets and installing,
> > tracking, and uninstalling kernel flows is
On Wed, Apr 18, 2012 at 01:21:17PM -0700, Ethan Jackson wrote:
> On Wed, Apr 18, 2012 at 11:30, Ethan Jackson wrote:
> > The addition of the ofpbuf stubs is a really useful optimization, but
> > it makes the memory management a bit more difficult to work out
> > conceptually, so please excuse me i
Looks good.
Ethan
On Tue, Apr 17, 2012 at 17:23, Ben Pfaff wrote:
> This makes a sequence of 10,000 "add-port" operations on a single ovs-vsctl
> command line about 4X faster. It makes a sequence of 10,000 "del-port"
> operations on a single command line over 2X faster.
>
> It works by not repo
Looks good, thanks.
Ethan
On Tue, Apr 17, 2012 at 17:23, Ben Pfaff wrote:
> Only the controller commands used these members and they didn't even help
> those commands very much.
>
> Signed-off-by: Ben Pfaff
> ---
> utilities/ovs-vsctl.c | 35 +--
> 1 files cha
Looks good, thanks.
Ethan
On Tue, Apr 17, 2012 at 17:23, Ben Pfaff wrote:
> It's only used in cmd_get_fail_mode(), which can easily look it up for
> itself, so there's no benefit to storing it in every vsctl_bridge record.
>
> Signed-off-by: Ben Pfaff
> ---
> utilities/ovs-vsctl.c | 16 +
Looks good, thanks.
Ethan
On Tue, Apr 17, 2012 at 17:23, Ben Pfaff wrote:
> To speed up management operations with many ports, we need to preserve the
> cache of bridges, ports, and interfaces from one operation to the next.
> One necessary step is to push the "struct vsctl_info" that did the ca
-Implemented support for ovs-test client, so that it could automatically
spawn an ovs-test server process from itself. This reduces the number of
commands the user have to type to get tests running.
-Automated creation of OVS bridges and ports (for VLAN and GRE tests), so that
user would not need t
Looks good, thanks.
Ethan
On Tue, Apr 17, 2012 at 17:23, Ben Pfaff wrote:
> A VLAN bridge uses its parent's controllers, so checking the controller
> should verify the parent's set of controllers.
>
> The change to verify_controllers() isn't necessary; it just deletes
> the check for a null 'bri
Looks good, thanks.
Ethan
On Tue, Apr 17, 2012 at 17:23, Ben Pfaff wrote:
> A VLAN bridge uses its parent's fail-mode, so checking the fail-mode should
> verify the parent's bridge record.
>
> This fixes a bug, but it is unlikely to ever have caused a real problem for
> users.
>
> Found by inspe
Looks good, thanks.
Ethan
On Mon, Apr 16, 2012 at 17:19, Ben Pfaff wrote:
> The copy of the extra flow copy here was showing up in profiles. We only
> need this copy if we end up doing a "trace" to warn the user. Most runs
> won't ever do that, so don't start making copies until we actually hi
Looks good, thanks.
Ethan
On Mon, Apr 16, 2012 at 17:19, Ben Pfaff wrote:
> This was showing up on profiles.
>
> Signed-off-by: Ben Pfaff
> ---
> ofproto/ofproto-dpif.c | 29 ++---
> 1 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/ofproto/ofproto-dp
Looks good, thanks.
Ethan
On Mon, Apr 16, 2012 at 17:19, Ben Pfaff wrote:
> This was showing up in profiles.
>
> Signed-off-by: Ben Pfaff
> ---
> ofproto/ofproto-dpif.c | 29 +++--
> 1 files changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/ofproto/ofproto-d
Quite an elegant data structure. Pretty nifty.
On Mon, Apr 16, 2012 at 17:19, Ben Pfaff wrote:
> The cost of creating and initializing facets and subfacets and installing,
> tracking, and uninstalling kernel flows is significant. When most flows
> have only one or a few packets, this overhead i
On Wed, Apr 18, 2012 at 11:30, Ethan Jackson wrote:
> The addition of the ofpbuf stubs is a really useful optimization, but
> it makes the memory management a bit more difficult to work out
> conceptually, so please excuse me if my following comment is
> misguided:
>
> It looks to me like handle_f
The addition of the ofpbuf stubs is a really useful optimization, but
it makes the memory management a bit more difficult to work out
conceptually, so please excuse me if my following comment is
misguided:
It looks to me like handle_flow_miss() can populate elements of
'ops->dpif_op.u.execute' wit
That makes sense. Looks good.
Ethan
On Wed, Apr 18, 2012 at 10:47, Ben Pfaff wrote:
> On Tue, Apr 17, 2012 at 07:03:49PM -0700, Ethan Jackson wrote:
>> I may be misreading the code, but nl_sock_transact_multiple__() seems
>> incorrect to me. It seems possible to me that we would swap tmp_reply
Yep, thanks.
Ethan
On Wed, Apr 18, 2012 at 09:21, Ben Pfaff wrote:
> On Tue, Apr 17, 2012 at 05:08:52PM -0700, Ethan Jackson wrote:
>> > + facet = facet_lookup_valid(ofproto, flow, miss->hmap_node.hash);
>>
>> Pulling the hash out of hmap_node directly makes me a bit nervous.
>> Does it make
Sounds good, thanks.
Ethan
On Wed, Apr 18, 2012 at 09:36, Ben Pfaff wrote:
> On Tue, Apr 17, 2012 at 05:21:03PM -0700, Ethan Jackson wrote:
>> Does nl_sock_allocate_seq() need to take 'n' as a parameter? It's
>> only caller passes in 1 currently. Perhaps a future patch will need
>> it?
>>
>> I
I think that this commit needs to get broken into two, with better
commit log. I'll work on that.
On Tue, Apr 17, 2012 at 03:46:00PM -0700, Ethan Jackson wrote:
> I'm having a bit of trouble understanding this patch.
>
> It seems to me like it continues to do accounting when removing
> facets, w
On Tue, Apr 17, 2012 at 07:03:49PM -0700, Ethan Jackson wrote:
> I may be misreading the code, but nl_sock_transact_multiple__() seems
> incorrect to me. It seems possible to me that we would swap tmp_reply
> for one of the replies in 'transactions'. Since tmp_reply is
> (potentially) stack alloc
On Tue, Apr 17, 2012 at 05:21:03PM -0700, Ethan Jackson wrote:
> Does nl_sock_allocate_seq() need to take 'n' as a parameter? It's
> only caller passes in 1 currently. Perhaps a future patch will need
> it?
>
> It's probably worth adding a comment to nl_sock_allocate_seq()
> explaining why it wr
On Tue, Apr 17, 2012 at 05:08:52PM -0700, Ethan Jackson wrote:
> > + facet = facet_lookup_valid(ofproto, flow, miss->hmap_node.hash);
>
> Pulling the hash out of hmap_node directly makes me a bit nervous.
> Does it make sense to store the hash directly in struct flow_miss with
> a comment about
30 matches
Mail list logo
