Hi,
With this mail we would like to re-focus the long-pending discussions on how to
best support new tunnel stacks such as MPLS in GRE and new tunneling protocols
like NSH in OVS.
Contributions addressing individual aspects of the problem complex (L3
tunneling, NSH) have been in the make for
> From: Jesse Gross [mailto:je...@kernel.org]
> Sent: Friday, 16 September, 2016 01:38
>
> I think the main issue is that when packets are being tunneled and NSH is in
> use, the encapsulation format (and therefore OVS port
> type) is not NSH - it's typically VXLAN-GPE. This is conceptually simil
> Sent: Tuesday, 06 September, 2016 16:31
> To: Jesse Gross
> Cc: Jan Scheurich; Li, Johnson; Simon Horman; dev@openvswitch.org; Miguel
> Angel Muñoz Gonzalez; Manuel Buil; László Sürü;
> Multanen, Eric W
> Subject: Re: [ovs-dev] NSH Option 2 implementation
>
> On Tue, Aug 23, 2
we submit the next version of
the patch. As it affects the north-bound interface of OVS for NSH, we should
have this agreed and frozen as soon as possible.
Thanks, Jan
> -Original Message-
> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Jan Scheurich
> Sent: Wedn
> From: Jesse Gross [mailto:je...@kernel.org]
> Sent: Wednesday, 24 August, 2016 04:48
>
> >> I'm still not enthusiastic about having a combined push NSH/Ethernet
> >> action. I don't think that it even really supports the full NSH use
> >> case since at least some of the patches sent are not using
> -Original Message-
> From: Jesse Gross [mailto:je...@kernel.org]
> Sent: Monday, 15 August, 2016 19:12
>
> On Fri, Aug 12, 2016 at 1:01 AM, Jan Scheurich
> wrote:
> > The only clean way to avoid that now would be to maintain the monolithic
> > push/p
-
> From: Li, Johnson [mailto:johnson...@intel.com]
> Sent: Friday, 12 August, 2016 03:55
> >
> > On Thu, Aug 11, 2016 at 12:58:44PM +, Jan Scheurich wrote:
> > > Hi Simon
> > >
> > > > > The implicit push_eth action introduced by Simon in his L3
&g
Hi Simon
> > The implicit push_eth action introduced by Simon in his L3 tunnel port
> > patch mainly ensures the presence of the 14 byte MAC header on ports
> > where this is a must for syntactic interpretation of the packet. It
> > did not worry about if the resulting packet was semantically usef
> > [Jan] Should sending a packet after push_nsh to an output port be
> > allowed in general? For a VXLAN-GPE tunnel port this is OK, but my
> > expectation was that one must explicitly do push_eth (followed by
> > set_field for dl_src and dl_dst) to be able to transmit on a normal
> > Ethernet po
bles and hence the average number of subtable
lookups from 2.5 to 3.5 on master with a corresponding decrease of throughput
to 1.2 Mpps. With the patch the parallel ping has no impact on average number
of subtable lookups and performance. The performance gain is then ~75%.
Signed-off-by: Jan Scheu
Hi Daniele,
Thanks for the review. I will send v5 asap.
A few answers inline below.
BR, Jan
From: Daniele Di Proietto [mailto:diproiet...@ovn.org]
Sent: Thursday, 11 August, 2016 02:59
To: Jan Scheurich
Cc: dev@openvswitch.org; antonio.fische...@intel.com
Subject: Re: [ovs-dev] [PATCH v4] dpif
+ [ovs-dev]
Further comments below.
BR, Jan
> -Original Message-
> From: Li, Johnson [mailto:johnson...@intel.com]
> Sent: Thursday, 11 August, 2016 03:36
> Subject: RE: NSH Option 2 implementation
>
> >
> > Hi Danny,
> >
> > thanks, for your quick response. I look forward to hearing fr
ing to split this in different patches to
> separate cpvector stuff, in any case all the content looks good
> to me.
>
> Thanks.
>
> Acked-by: Antonio Fischetti
>
>
>> -Original Message-
>> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Jan
&
ith a corresponding decrease of throughput
to 1.2 Mpps. With the patch the parallel ping has no impact on average number
of subtable lookups and performance. The performance gain is then ~75%.
Signed-off-by: Jan Scheurich
Changes in v4:
- Renamed cpvector back to pvector after Jarno's revert patch
> -Original Message-
> From: Simon Horman [mailto:simon.hor...@netronome.com]
> Sent: Wednesday, 10 August, 2016 12:14
> >
> > My suggestion for the action set execution order would therefore be:
> > 3.a push_nsh
> > 3.b push_eth
> > 3.c push_mpls
> > 4 push_pbb
> > 5 push_vlan
it for 2.6. Please advise.
Thanks, Jan
From: Jarno Rajahalme [mailto:ja...@ovn.org]
Sent: Tuesday, 09 August, 2016 22:04
To: Jan Scheurich
Cc: dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v3] dpif-netdev: dpcls per in_port with sorted
subtables
On Aug 9, 2016, at 7:08 AM, Jan Scheurich
I just submitted a v3 version of the patch. No need to review this one.
Jan
> -Original Message-
> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Jan Scheurich
> Sent: Friday, 15 July, 2016 18:35
> To: dev@openvswitch.org
> Subject: [ovs-dev] [PATCH v2] dpi
into OVS 2.6.
Thanks, Jan
> -Original Message-
> From: Jan Scheurich [mailto:jan.scheur...@web.de]
> Sent: Tuesday, 09 August, 2016 16:08
> To: dev@openvswitch.org
> Cc: jan.scheur...@web.de
> Subject: [PATCH v3] dpif-netdev: dpcls per in_port with sorted subtables
&
of subtables and hence the average number of subtable
lookups from 2.5 to 3.5 on master with a corresponding decrease of throughput
to 1.2 Mpps. With the patch the parallel ping has no impact on average number
of subtable lookups and performance. The performance gain is then ~75%.
Signed-off-by: Jan
> From: Jarno Rajahalme [mailto:ja...@ovn.org]
> Sent: Friday, 29 July, 2016 20:38
>
> > Twice the memory of the steady state footprint would still be a significant
> burden, in particular if that memory would have to reside on hugepages that
> are statically reserved for ovs-vswitchd. I must say
Hi Jarno,
While trying to rebase my "dpcls per in_port" patch to your updated
pvector/cpvector implementation, I have stumbled over a threading issue in your
patch.
I believe that dpcls_destroy_subtable(), which may be invoked from revalidater
threads at flow removal, should not simply call th
Hi,
I agree that we should go ahead with implementing support for MD2 while we are
doing NSH. There are planned use cases that will depend on MD2, like an SFF
load-sharing between SF instances based on an entropy TLV option.
But there are in fact a number of technical issues that need to be sor
Yang, Yi Y [mailto:yi.y.y...@intel.com]
> Sent: Thursday, 21 July, 2016 03:44
> To: Jan Scheurich; Li, Johnson; dev@openvswitch.org
> Cc: Simon Horman
> Subject: RE: [ovs-dev] [RFC PATCH v2 12/13] Commit push_eth/pop_eth flow
> action to data plane
>
> It's clear en
of NSH headers into
metadata fields at pop_mpls and implicit loading from metadata at push_nsh. But
perhaps that use case will never be needed
> -Original Message-
> From: Yang, Yi Y [mailto:yi.y.y...@intel.com]
> Sent: Wednesday, 20 July, 2016 04:30
> To: Jan Scheurich; Li, Jo
ave a look at flow_pop_mpls() function in flow.c for an idea
how to do this).
BR, Jan
> -Original Message-
> From: Yang, Yi Y [mailto:yi.y.y...@intel.com]
> Sent: Wednesday, 20 July, 2016 04:00
> To: Jan Scheurich; Li, Johnson; dev@openvswitch.org
> Cc: Simon Horman
>
Hi Antonio,
Thanks for the review. I will fix all the editorials in v3.
A few more answers inline.
Thanks, Jan
> -Original Message-
> From: Fischetti, Antonio [mailto:antonio.fische...@intel.com]
> Sent: Tuesday, 19 July, 2016 17:23
>
> Hi Jan,
> I added some comments prefixed with [Anton
No problem, Jesse.
As this is mainly about the northbound OpenFlow interface for NSH, is there
anybody else would want to chime in?
Thanks, Jan
> -Original Message-
> From: Jesse Gross [mailto:je...@kernel.org]
> Sent: Tuesday, 19 July, 2016 18:39
> To: Jan Scheuri
age-
> From: Jan Scheurich
> Sent: Friday, 15 July, 2016 12:27
>
> It would be great if we could get guidance by the OVS committers on below
> question whether to model NSH fields as packet header match fields or as
> metada fields or both.
>
> Right now patch v2 mixes tho
Hi Johnson,
After basing these patches on Simon's L3 tunneling support the push_eth action
should take the flow-> base_layer into account:
If it is LAYER_2, pushing an Ethernet header encapsulates the inner L2 frame
and therefore requires a call to xlate_commit_actions(ctx) before composing the
Hi Johnson,
> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Yang, Yi
> Sent: Monday, 18 July, 2016 12:37
>
> On Mon, Jul 18, 2016 at 03:15:13PM +0900, Simon Horman wrote:
> > Hi Johnson,
> >
> > On Wed, Jul 13, 2016 at 01:28:48AM +0800, Johnson Li wrote:
> > > Signed-off-by: Johnson
> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Simon Horman
> Sent: Monday, 18 July, 2016 14:14
> >
> > Simon, very good guide, do push_eth and pop_eth also need to follow
> > this?
>
> Not exactly.
>
> As of v12 of the patch-set there are two phases, compose and commit.
> This was
with the
design base code and also improves the number of subtable lookups in a miss
case.
The PMD tests have been adjusted to the additional line in pmd-stats-show.
Signed-off-by: Jan Scheurich
Changes in v2:
- Rebased to master (commit 3041e1fc9638)
- Take the pmd->flow_mutex dur
It would be great if we could get guidance by the OVS committers on below
question whether to model NSH fields as packet header match fields or as metada
fields or both.
Right now patch v2 mixes those and uses the same set of NXM fields both when
matching packet headers of an NSH packet and as
The push_nsh action creates a non-Ethernet packet in the OF pipeline, which is
not at all supported by OVS prior to Simon's patch. It is not good enough to
promise that an SFC controller will always send a push_eth action right next to
fix this.
A new action in OVS must be sane in the sense tha
First of all, Ericsson fully supports the initiative to provide support for NSH
encapsulation in OVS.
Based on earlier RFC patch sets and mailing list discussions the solution
should be based on the following principles:
A. Align with existing OpenFlow paradigms and OVS implementation architec
> From: Jan Scheurich
> Sent: Thursday, 07 July, 2016 10:28
>
> I actually have some doubts about thread safety of the dpcls complex. My
> understanding is that dpcls rules are inserted only by the owning PMD thread
> itself as result of processing upcalls. But dplcs ru
> From: Jarno Rajahalme [mailto:ja...@ovn.org]
> Sent: Monday, 04 July, 2016 14:06
>
> I like this RFC patch and suggest you send a non-RFC patch after taking care
> of the following:
Thanks for the review. Will implement all requested changes and submit non-RFC
PATCH v2 when ready.
> - You sho
md-stats-show.
Signed-off-by: Jan Scheurich
---
lib/dpif-netdev.c | 184
+++---
tests/pmd.at | 6 +++--
2 files changed, 165 insertions(+), 25 delet
> >> Did you consider keeping a separate dpcls instance per input port instead?
> >> I.e., have an hmap of dpcls'es using the in_port as the hash key, and
> >> creating and destroying them on demand. This would avoid the fixed
> >> size array, simplify the code and each insert and remove operation
>> Refreshing the 250K flow entries using the bundle mechanism increases
>> the vswitchd memory linearly up to 1.9 GB, significantly more than the 910
>> MB one would expect for accommodating two versions of each rule at the
>> moment of the atomic activation.
>
> The reason for the high(er) memor
,bucket=actions=output:3
Patch v3:
- Rebased to master
Patch v2:
- Replaced new ovs-ofctl write-group command with --may-create option for
mod-group
- Updated ovs-ofctl --help message
- Added a test for the new command option
- Updated documentation
Signed-off-by: Jan Scheurich
---
NEWS
Hi,
We would like to resume our earlier discussion about how to support a simple,
generic and efficient procedure for controllers to resync all OF forwarding
state with OVS after a reconnect while maintaining non-stop forwarding (see
http://openvswitch.org/pipermail/dev/2016-January/064925.html
bmit a new version that fixes this.
Thanks, Jan
> -Original Message-----
> From: Jan Scheurich [mailto:jan.scheur...@web.de]
> Sent: Monday, 06 June, 2016 00:31
> To: dev@openvswitch.org
> Cc: jan.scheur...@web.de
> Subject: [PATCH v2]: ofproto: Add relaxed group_mod command
> This no longer applies cleanly, and I also needed to add this incremental to
> make the testsuite pass:
I will rebase and adapt the tests as suggested in the next version.
> Did you consider keeping a separate dpcls instance per input port instead?
> I.e., have an hmap of dpcls'es using the in_
> [Antonio F]
> What if the range of the hash values is partitioned per port type?
> I mean if the 1st range - say the first 10 values - are reserved for dpdk
> ports
>
> if // range is [0..9]
> uint32_t port_idx = 0 + hash_port_no(port_no) % 10;
> else// range is [10..NUM_SUBTABLE_VECT
average number of subtable lookups and
performance. The performance gain is then ~50%.
Signed-off-by: Jan Scheurich
-
lib/dpif-netdev.c | 110
---
1 file changed, 92 insertions(+), 18 deletions(-)
diff -
I very much support the proposal to make configuration of "physical" DPDK ports
more explicit and flexible. Both the ability to specify the port by its PCI
address as well as the ability to choose arbitrary port names are highly
welcome.
+1 for idea and implementation.
Can we combine this prop
,bucket=actions=output:3
Patch v2:
- Replaced new ovs-ofctl write-group command with --may-create option for
mod-group
- Updated ovs-ofctl --help message
- Added a test for the new command option
- Updated documentation
Signed-off-by: Jan Scheurich
To aid review this patch is available at
On Thu, 2 Jun 2016 16:03:02 -0700
Ben Pfaff wrote:
>
> In the documentation, please note that this uses an Open vSwitch
> extension to OpenFlow and that it only works with Open vSwitch 2.6 or
> later.
>
I'm a bit lost where to put this information. Is there a documentation
file that gathers al
Hi Ben,
Thanks for the review. Will update.
> In some places, this is called "add_or_modify" and in other places just
> "write". I suggest using a consistent name.
Which one would you suggest?
BR, Jan
___
dev mailing list
dev@openvswitch.org
http://op
> Disabling the EMC on master I have measured a baseline performance
> (in+out) of ~1.32 Mpps (64 bytes, 1000 L4 flows). The average number of
> subtable lookups per megaflow match is 2.5.
Just running parallel ping between the tunnel end-point IPs on the two
servers increases the number of subt
> The true value of sorting subtables will only materialize when having
> one sorted list per ingress port. Due to RSS and vhost-user
> multi-queue I am afraid that, when performance really matters, each
> port will be split over more than one PMD and every PMD will serve
> many ports. There is no
Could someone perhaps have a look at the latest version of the patch?
Thanks a lot, Jan
On Sat, 21 May 2016 00:42:49 +0200
Jan Scheurich wrote:
> *** Reposting the patch once more. First two attempts got corrupted
> *** *** Sorry, still trying to find a suitable email client ***
>
):
group_id=100,type=indirect,bucket=actions=output:2
ovs-ofctl -Oopenflow13 write-group br-int
group_id=100,type=indirect,bucket=actions=3 ovs-ofctl -Oopenflow13
dump-groups br-int OFPST_GROUP_DESC reply (OF1.3) (xid=0x2):
group_id=100,type=indirect,bucket=actions=output:3
Signed-off-by: Jan Scheurich
-group br-int
group_id=100,type=indirect,bucket=actions=3 ovs-ofctl -Oopenflow13
dump-groups br-int OFPST_GROUP_DESC reply (OF1.3) (xid=0x2):
group_id=100,type=indirect,bucket=actions=output:3
Signed-off-by: Jan Scheurich
To aid review this series is available at:
tree: https://github.com
> >> What we do see, however is that there is often a strong correlation
> >> between the ingress port and the subset of masks/subtables that have
> >> hits. The entire megaflow cache typically decomposes nicely into
> >> partitions that are hit only by packets entering from equivalent
> >> ports (
Am 19.05.2016 um 22:47 schrieb pravin shelar:
On Wed, May 18, 2016 at 9:41 AM, Jan Scheurich wrote:
I agree current tunneling port check is bit arbitrary. It was designed
to handle most common tunneling setup. But I do not think we can allow
tunneling on any type of port. For example I doubt
ovs-ofctl -Oopenflow13 dump-groups br-int
OFPST_GROUP_DESC reply (OF1.3) (xid=0x2):
group_id=100,type=indirect,bucket=actions=output:3
Signed-off-by: Jan Scheurich
To aid review this patch is available at:
tree: https://github.com/JScheurich/openvswitch
branch: dev/group_add_modify
tag
Hi,
> The current ACL implementation is using rules as {ProtocolType, IPsrc, IPdest,
> PortSrc, PortDest}, so I'm limited to play just with these 5 fields.
>
From experience with real-world OVS deployments using bonded interfaces and
overlay tunnels (e.g. VXLAN) I would say that the vast majori
Pfaff [mailto:b...@ovn.org]
>
> On Wed, May 11, 2016 at 01:30:58PM +, Jan Scheurich wrote:
> > A simple solution to this problem would be an additional, more
> > tolerant Group Mod command (e.g. ADD_OR_MODIFY) that writes a group
> > into the group table no matter if it
ifconfig tep1 10.1.2.10/24 up
ifconfig tep2 10.1.3.10/24 up
Tunnel connectivity over a setup like the above has been manually tested.
Signed-off-by: Jan Scheurich
---
ofproto/ofproto-dpif-xlate.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/ofproto/ofproto
In OpenFlow 1.x the Group Mod commands OFPGC_ADD and OFPGC_MODIFY have strict
semantics: ADD fails if the group exists, while MODIFY fails if the group does
not exist.
This requires a controller to exactly know the state of the switch when
programming a group in order not run the risk of gettin
We are trying to set up user-space tunneling with DPDK datapath in OVS 2.5
using other internal ports on the external bridge (br-prv) than the LOCAL
bridge port as local tunnel end-points. The ultimate goal is to configure the
different internal ports on br-prv as VLAN access ports with differen
000 1401134 2170788
> -Original Message-
> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Jan Scheurich
>
> I would like to confirm that Thomas's use case is key also for the BGP/MPLS
> VPN
> implementation in Open Daylight. In our case OVS is forwarding MPLS
I would like to confirm that Thomas's use case is key also for the BGP/MPLS VPN
implementation in Open Daylight. In our case OVS is forwarding MPLSoGRE
encapsulated L3 VPN traffic from physical ports as IP packets to VMs on
vhost-user ports.
Even without the additional recirculation after pop_m
In general we agree that it would be good to extend the OVS bundle support to
cover groups and meters in accordance with the OF 1.4 specification and that it
would be helpful to also make it available as extension to OF 1.3 according to
ONF #230.
However, we still have doubts whether the bundle
> The 64 bit cookie can be used for storing the generation-id. OVS supports
> blowing away all rules which
> match a cookie value/mask.
As far as I know only flows have cookies in OpenFlow, so this approach cannot
deal with resync of groups and meters.
__
>
> I don't see how the proposed feature is better than what we already have. It
> saves a little memory temporarily, but memory isn't
> usually a big deal in typical OVS environments. Is there some other
> advantage?
A couple of points that come into my mind:
1. OpenFlow bundle depends on O
Our hit-less resync proposal is not really about atomic updates to flow tables.
It is rather a generic, simple, and efficient way for an SDN controller to
ensure that the entire flow state (flows, groups, meters) of a switch is
re-aligned with the master state on the controller, while continuing
69 matches
Mail list logo
