[ovs-dev] [PATCH] LISP: update documentation for "null" ports
Since commit 0ad90c8 it is possible to set tunnel destination IP address in the flow. This allows creating a LISP "map-cache" in the flow table. Update the LISP documentation to reflect these possibilities. Signed-off-by: Lorand Jakab --- README-lisp | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/README-lisp b/README-lisp index 7c9071a..5bf44ac 100644 --- a/README-lisp +++ b/README-lisp @@ -6,11 +6,12 @@ not carry Ethernet headers, and ARP requests shouldn't be sent over the tunnel. Because of this, there are some additional steps required for setting up LISP tunnels in Open vSwitch, until support for L3 tunnels will improve. -This guide assumes a point-to-point tunnel between two VMs connected to OVS -bridges on different hypervisors connected via IPv4. Of course, more than one -VM may be connected to any of the hypervisors, using the same LISP tunnel, and -a hypervisor may be connected to several hypervisors over different LISP -tunnels. +This guide assumes tunneling between two VMs connected to OVS bridges on +different hypervisors reachable over IPv4. Of course, more than one VM may be +connected to any of the hypervisors, and a hypervisor may communicate with +several different hypervisors over the same lisp tunneling interface. A LISP +"map-cache" can be implemented using flows, see example at the bottom of this +file. There are several scenarios: @@ -58,11 +59,14 @@ bridge instance, and become numbered 1, 2, and 3 respectively: ovs-vsctl add-br br0 ovs-vsctl add-port br0 tap0 ovs-vsctl add-port br0 eth0 -ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp options:remote_ip= +ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp options:remote_ip=flow options:out_key=flow options:in_key=flow Flows on br0 are configured as follows: priority=3,dl_dst=02:00:00:00:00:00,action=mod_dl_dst:,output:1 priority=2,in_port=1,dl_type=0x0806,action=NORMAL - priority=1,in_port=1,dl_type=0x0800,vlan_tci=0,nw_src=,action=output:3 + priority=1,in_port=1,dl_type=0x0800,vlan_tci=0,nw_src=,action=set_field:->tun_dst,output:3 priority=0,action=NORMAL + +Optionally, if you want to use Instance ID in a flow, you can set it with +"action=set_tunnel=". -- 1.8.1.5 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] LISP: update documentation for "null" ports
On May 27, 2013, at 12:35 , ext Lorand Jakab wrote: > Since commit 0ad90c8 it is possible to set tunnel destination IP address > in the flow. This allows creating a LISP "map-cache" in the flow table. > Update the LISP documentation to reflect these possibilities. > > Signed-off-by: Lorand Jakab > --- > README-lisp | 18 +++--- > 1 file changed, 11 insertions(+), 7 deletions(-) > > diff --git a/README-lisp b/README-lisp > index 7c9071a..5bf44ac 100644 > --- a/README-lisp > +++ b/README-lisp > @@ -6,11 +6,12 @@ not carry Ethernet headers, and ARP requests shouldn't be > sent over the > tunnel. Because of this, there are some additional steps required for setting > up LISP tunnels in Open vSwitch, until support for L3 tunnels will improve. > > -This guide assumes a point-to-point tunnel between two VMs connected to OVS > -bridges on different hypervisors connected via IPv4. Of course, more than > one > -VM may be connected to any of the hypervisors, using the same LISP tunnel, > and > -a hypervisor may be connected to several hypervisors over different LISP > -tunnels. > +This guide assumes tunneling between two VMs connected to OVS bridges on > +different hypervisors reachable over IPv4. Of course, more than one VM may > be > +connected to any of the hypervisors, and a hypervisor may communicate with > +several different hypervisors over the same lisp tunneling interface. A LISP > +"map-cache" can be implemented using flows, see example at the bottom of this > +file. > > There are several scenarios: > > @@ -58,11 +59,14 @@ bridge instance, and become numbered 1, 2, and 3 > respectively: > ovs-vsctl add-br br0 > ovs-vsctl add-port br0 tap0 > ovs-vsctl add-port br0 eth0 > -ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp > options:remote_ip= > +ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp > options:remote_ip=flow options:out_key=flow options:in_key=flow > This can be simplified a bit by using "options:key=flow", which implies both "out_key=flow" and "in_key=flow", so it would become: +ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp options:remote_ip=flow options:key=flow > Flows on br0 are configured as follows: > > priority=3,dl_dst=02:00:00:00:00:00,action=mod_dl_dst:,output:1 > priority=2,in_port=1,dl_type=0x0806,action=NORMAL > - > priority=1,in_port=1,dl_type=0x0800,vlan_tci=0,nw_src=,action=output:3 > + > priority=1,in_port=1,dl_type=0x0800,vlan_tci=0,nw_src=,action=set_field:->tun_dst,output:3 > priority=0,action=NORMAL > + > +Optionally, if you want to use Instance ID in a flow, you can set it with > +"action=set_tunnel=". The syntax here should be: +"action=set_tunnel:". Jarno ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] LISP: update documentation for "null" ports
Thanks for the review Jarno, will send out a revised patch. -Lori On 05/27/2013 01:20 PM, Rajahalme, Jarno (NSN - FI/Espoo) wrote: > > On May 27, 2013, at 12:35 , ext Lorand Jakab wrote: > >> Since commit 0ad90c8 it is possible to set tunnel destination IP address >> in the flow. This allows creating a LISP "map-cache" in the flow table. >> Update the LISP documentation to reflect these possibilities. >> >> Signed-off-by: Lorand Jakab >> --- >> README-lisp | 18 +++--- >> 1 file changed, 11 insertions(+), 7 deletions(-) >> >> diff --git a/README-lisp b/README-lisp >> index 7c9071a..5bf44ac 100644 >> --- a/README-lisp >> +++ b/README-lisp >> @@ -6,11 +6,12 @@ not carry Ethernet headers, and ARP requests shouldn't be >> sent over the >> tunnel. Because of this, there are some additional steps required for >> setting >> up LISP tunnels in Open vSwitch, until support for L3 tunnels will improve. >> >> -This guide assumes a point-to-point tunnel between two VMs connected to OVS >> -bridges on different hypervisors connected via IPv4. Of course, more than >> one >> -VM may be connected to any of the hypervisors, using the same LISP tunnel, >> and >> -a hypervisor may be connected to several hypervisors over different LISP >> -tunnels. >> +This guide assumes tunneling between two VMs connected to OVS bridges on >> +different hypervisors reachable over IPv4. Of course, more than one VM may >> be >> +connected to any of the hypervisors, and a hypervisor may communicate with >> +several different hypervisors over the same lisp tunneling interface. A >> LISP >> +"map-cache" can be implemented using flows, see example at the bottom of >> this >> +file. >> >> There are several scenarios: >> >> @@ -58,11 +59,14 @@ bridge instance, and become numbered 1, 2, and 3 >> respectively: >> ovs-vsctl add-br br0 >> ovs-vsctl add-port br0 tap0 >> ovs-vsctl add-port br0 eth0 >> -ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp >> options:remote_ip= >> +ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp >> options:remote_ip=flow options:out_key=flow options:in_key=flow >> > > This can be simplified a bit by using "options:key=flow", which implies both > "out_key=flow" and "in_key=flow", so it would become: > > +ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp > options:remote_ip=flow options:key=flow > >> Flows on br0 are configured as follows: >> >> priority=3,dl_dst=02:00:00:00:00:00,action=mod_dl_dst:,output:1 >> priority=2,in_port=1,dl_type=0x0806,action=NORMAL >> - >> priority=1,in_port=1,dl_type=0x0800,vlan_tci=0,nw_src=,action=output:3 >> + >> priority=1,in_port=1,dl_type=0x0800,vlan_tci=0,nw_src=,action=set_field:->tun_dst,output:3 >> priority=0,action=NORMAL >> + >> +Optionally, if you want to use Instance ID in a flow, you can set it with >> +"action=set_tunnel=". > > The syntax here should be: > > +"action=set_tunnel:". > > Jarno > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCHv2] LISP: update documentation for "null" ports
Since commit 0ad90c8 it is possible to set tunnel destination IP address in the flow. This allows creating a LISP "map-cache" in the flow table. Update the LISP documentation to reflect these possibilities. Signed-off-by: Lorand Jakab --- Changes in v2: * Comments from Jarno Rajahalme --- README-lisp | 18 +++--- 1 files changed, 11 insertions(+), 7 deletions(-) diff --git a/README-lisp b/README-lisp index 7c9071a..e0e1ffd 100644 --- a/README-lisp +++ b/README-lisp @@ -6,11 +6,12 @@ not carry Ethernet headers, and ARP requests shouldn't be sent over the tunnel. Because of this, there are some additional steps required for setting up LISP tunnels in Open vSwitch, until support for L3 tunnels will improve. -This guide assumes a point-to-point tunnel between two VMs connected to OVS -bridges on different hypervisors connected via IPv4. Of course, more than one -VM may be connected to any of the hypervisors, using the same LISP tunnel, and -a hypervisor may be connected to several hypervisors over different LISP -tunnels. +This guide assumes tunneling between two VMs connected to OVS bridges on +different hypervisors reachable over IPv4. Of course, more than one VM may be +connected to any of the hypervisors, and a hypervisor may communicate with +several different hypervisors over the same lisp tunneling interface. A LISP +"map-cache" can be implemented using flows, see example at the bottom of this +file. There are several scenarios: @@ -58,11 +59,14 @@ bridge instance, and become numbered 1, 2, and 3 respectively: ovs-vsctl add-br br0 ovs-vsctl add-port br0 tap0 ovs-vsctl add-port br0 eth0 -ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp options:remote_ip= +ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp options:remote_ip=flow options:key=flow Flows on br0 are configured as follows: priority=3,dl_dst=02:00:00:00:00:00,action=mod_dl_dst:,output:1 priority=2,in_port=1,dl_type=0x0806,action=NORMAL - priority=1,in_port=1,dl_type=0x0800,vlan_tci=0,nw_src=,action=output:3 + priority=1,in_port=1,dl_type=0x0800,vlan_tci=0,nw_src=,action=set_field:->tun_dst,output:3 priority=0,action=NORMAL + +Optionally, if you want to use Instance ID in a flow, you can set it with +"action=set_tunnel:". -- 1.7.7.5 (Apple Git-26) ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Stone mosaic and Glass mosaic and Metal mosaic与您共享了相册。
6820265128234280001578466900947529940133927724625169492041524547034561066237973222301261142215177315My dear friend, How’s your business recently? We are writing to update you our new designs in 2013, we are special in manufacturing and designing the mosaic tiles, including the marble stone mosaic and glass mosaic and metal mosaic, ect. With more than 10 years production and export experience, we have successfully developed thousands of mosaic designs to meet the need of different market! And we can also make it according to your own designs or requirements! If you are interested in our mosaics, we would like to send you our catalogue and pricelist for your reference, we are expecting your kind prompt reply and feedback! Thanks in advance! --- Thanks & best regards Sabrina Law General manager Mosaic Factory Add.: Foshan Guangdong China RIWgPPCCdmybuZyPcQNHGDaJUaWizAVXgElOeKRksiNIJHMxqycDoEILCbEjTPDYOFTdMMzlNjvKrJvzZNKEWTqMlqnyBQmnxGBfBUoHBrWfgejUNUzMLbfiZyNGqYavXcqAVjWIjGFhOgRWvWhbtqNjHAwHYnJwGdYCDkEKSHnwwvAXelPcbsvfWvKDnVXsUZnjSgFFgpCexdBTsTeYqZwgrxtEVkstDaVzAhnHPEkfgejUbiyZYpehZybGElavlcqAjiWWxFSuUzYqCqnhzwTDOTQbstPQaxeIXEKdmbHC https://picasaweb.google.com/lh/sredir?uname=108073701594970919637&target=ALBUM&id=5880728927716434673&authkey=Gv1sRgCO62i-aEp6eyKw&invite=CIndhvcL&feat=email <><>___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v10 4/4] Add packet recirculation
On Fri, May 24, 2013 at 08:43:59AM +, Rajahalme, Jarno (NSN - FI/Espoo)
wrote:
> Simon,
>
> Here is some initial review of the ofproto-dpif.c changes,
Thanks, very much appreciated.
> Jarno
>
> On May 24, 2013, at 10:18 , ext Simon Horman wrote:
>
> > diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
> > index 49f0270..8b1ccac 100644
> > --- a/ofproto/ofproto-dpif.c
> > +++ b/ofproto/ofproto-dpif.c
> > @@ -43,6 +43,7 @@
> > #include "odp-util.h"
> > #include "ofp-util.h"
> > #include "ofpbuf.h"
> > +#include "odp-execute.h"
> > #include "ofp-actions.h"
> > #include "ofp-parse.h"
> > #include "ofp-print.h"
> > @@ -121,7 +122,8 @@ static struct rule_dpif *rule_dpif_miss_rule(struct
> > ofproto_dpif *ofproto,
> >
> > static void rule_credit_stats(struct rule_dpif *,
> > const struct dpif_flow_stats *);
> > -static void flow_push_stats(struct facet *, const struct dpif_flow_stats
> > *);
> > +static void flow_push_stats(struct facet *, const struct dpif_flow_stats *,
> > +const struct ofpact *, size_t ofpacts_len);
> > static tag_type rule_calculate_tag(const struct flow *,
> >const struct minimask *, uint32_t basis);
> > static void rule_invalidate(const struct rule_dpif *);
> > @@ -289,6 +291,17 @@ struct action_xlate_ctx {
> > uint16_t nf_output_iface; /* Output interface index for NetFlow. */
> > mirror_mask_t mirrors; /* Bitmap of associated mirrors. */
> >
> > +size_t ofpacts_len; /* The number of bytes of the ofpacts
> > + * argument to xlate_actions() processed
> > + * by it. This is used to calculate an
> > + * offset into ofpacts for calls to
> > + * xlate_actions on recirculated packets */
> > +
> > +uint32_t recirculation_id; /* skb_mark to use to identify
> > + * recirculation. */
>
> If this was 0 by default, and set to a valid recirculation_id when
> recirculation is to take place, then you might get rid of the bool
> recirculated?
There are two cases where recirculation_id is not 0 by default.
1. When RECIRCULATION_ID_DUMMY is used. This is the case when
executing without a facet, either when handling a flow miss
without a facet or when handling packet_out.
The purpose of using RECIRCULATION_ID_DUMMY is to avoid the overhead
of "allocating" a recirculation_id and the hassle of "freeing"
the recirculation_id. This is because without a facet the
recirculation_id used is local to the processing being performed.
2. When revalidating facets.
a. In order to produce a consistent translation of actions in the presence
of recirculation the recirculation_id of the facet being revalidated
is used as the initial value of the recirculation_id element of struct
action_xlate_ctx.
b. A facet's recirculation_id is used as the seed value of a
struct action_xlate_ctx in order to avoid unnecessary allocation of
recirculation_ids when walking the chain of facets that results from
a rule that causes recirculation. In this case the recirculated bit
is used to detect if the facet still adds a recirculation action or
not.
In order to make the usage of recirculation_id clearer I will update its
comment as follows.
uint32_t recirculation_id; /* skb_mark to use to identify recirculation.
* If RECIRCULATION_ID_NONE at the time
* that a recirculate action is added then
* get_recirculation_id() is used to obtain
* a recirculation id which is saved in
* recirculation_id.
* Otherwise the value recirculation_id is
* used.
* In this way both the value of the
* recirculation_id used and the need to
* call get_recirculation_id() may be
* controlled.
* The value RECIRCULATION_ID_DUMMY may
* be used as a temporary recirculation id.
*/
I will also update some of the comments in facet_revalidate() as follows:
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index 6258783..97ff9f8 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -5530,9 +5543,8 @@ facet_revalidate(struct facet *facet)
xlate_actions(&ctx, ofpacts, ofpacts_len, &odp_actions);
if (f->recirculation_id != RECIRCULATION_ID_NONE && !ctx.recirculated)
{
- /* If the facet no longer adds a recirculation action or is
-* queued up for removal then In this case
Re: [ovs-dev] [PATCH net-next v5 0/2] MPLS: Add limited GSO support
From: Simon Horman Date: Fri, 24 May 2013 16:02:50 +0900 > In the case where a non-MPLS packet is received and an MPLS stack is > added it may well be the case that the original skb is GSO but the > NIC used for transmit does not support GSO of MPLS packets. > > The aim of this short series is to provide GSO in software for MPLS packets > whose skbs are GSO. Looks good, and harmless, applied, thanks! ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] 802.3ad link aggregation protocol support for bonding
Hello. I'm try to use google, but it says that 802.3ad not implemented in ovs. Does 802.3ad support for bonding planning somewhere in roadmap? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] 802.3ad link aggregation protocol support for bonding
LACP has been supported for quite a while. --Justin On May 27, 2013, at 11:02 PM, Vasiliy Tolstov wrote: > Hello. I'm try to use google, but it says that 802.3ad not implemented in ovs. > Does 802.3ad support for bonding planning somewhere in roadmap? > > > -- > Vasiliy Tolstov, > e-mail: v.tols...@selfip.ru > jabber: v...@selfip.ru > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
