[ovs-dev] hi
こんにちは 私の名前は私はそれが良好な関係のために私の興味をかき立てると言わなければならないアロエベラですが、私は愛と友情を交換するためにあなたの詳細を知りたいので、私の メールID（veramat...@yahoo.com）を通して私にメールを送ること自由に感じなさいその私はあなたに私の写真を送るので、それはここ、ここから移動す る世話をすることができ、メールをmyself.awaitingについての詳細を教えてくれます。 Hello my name is vera i must say it spark my interest for a good relationship,i will like to know you more to exchange love and friendship, Please feel free to send me a mail through my mail id ( veramat...@yahoo.com ) so that i will send you my picture and tell you more about myself.awaiting your mail so that can here move on from here,Take care. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] ovsdb implementation
2013/10/5 Ben Pfaff : >> Hello, Ben. Yes i'm try to write golang ovsdb package to contol >> vSwitch from my own golang controller =). > > Oh, interesting. I don't know much about Go. =) > >> I need to dynamically create gre and vxlan tunnels now. > > It seems to be little-known but you can use GRE and VXLAN without > creating a separate interface for each tunnel. The best explanation is > in a commit message: > > commit 0ad90c845b7e82090a846fbe9f927e8d1c84cfc9 > Author: Jarno Rajahalme > Date: Thu May 9 15:24:16 2013 +0300 > > OpenFlow-level flow-based tunneling support. > > Adds tun_src and tun_dst match and set capabilities via new NXM fields > NXM_NX_TUN_IPV4_SRC and NXM_NX_TUN_IPV4_DST. This allows management of > large number of tunnels via the flow tables, without requiring the tunnels > to be pre-configured. > > Flow-based tunnels can be configured with options remote_ip=flow and > local_ip=flow. local_ip=flow requires remote_ip=flow. When set, the > tunnel remote IP address and/or local IP address is set from the flow, > instead of the tunnel configuration. > > Example: > > $ ovs-vsctl add-port br0 gre -- set Interface gre ofport_request=1 > type=gre options:remote_ip=flow options:key=flow > $ ovs-ofctl add-flow br0 "in_port=LOCAL > actions=set_tunnel:1,set_field:192.168.0.1->tun_dst,output:1" > $ ovs-ofctl add-flow br0 "in_port=1 tun_src=192.168.0.1 tun_id=1 > actions=LOCAL" > > Signed-off-by: Jarno Rajahalme > Signed-off-by: Ben Pfaff > Thanks, that is very good feature. As i understand commands above creates interface gre for that remote_ip and key extracted from the flow. Seconds command establish flow for local port and for each gre tunnel established from remote host extracts tun_dst and outputs to port 1? Third command sets tun_id and tun_src ... If i need to create gre tunnels like this, but count of node1...node2... is about 60, does this flow rules works ? as i understand i need specify gre tun_dst on each gw and on node i need only this three rules? gw1 gw2 /\ / \ / / \ / / \ \ gre0gre1 gre0gre1 | | | | | | | | ovs-tun ovs-tun | | ovs-vmovs-vm node1 node2 > The one big weakness to this support is that there's currently no way > to enable CFM or BFD without adding an interface. > Hmm.. Does adding this is planning feature in case of flow -based tunnels ? >> When i'm create full support for all ovsdb things i'm glad to >> contribute my work to open vSwitch project. > > That sounds nice, thanks! =) -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] sFlow export: include standard tunnel structures (for GRE, VXLAN etc.)
Please comment on this proposed patch. It adds the standard
sFlow-TUNNEL structures to the sFlow export, which will be helpful
for tracing tunneled traffic through a network fabric in real-time.
As part of doing that, it switches over from using odp_port to ofp_port
as the port reference used in dpif-sflow, which allows some only-for-sflow
code to be removed elsewhere. It also completely removes the private
port-lookup hash table that dpif-sflow was maintaining and replaces
it with a simple callback to the parent dpif - presenting the parent with
a structure to fill in with just the necessary details about the port.
This makes it easier for the parent dpif to control what port state is
exposed to the sFlow module during the processing of a packet-sample.
(This same mechanism can now be extended to expose some
bundle/LAG information, so the standard sFlow-LAG structures can
be exported too, but that can be in another patch).
This patch also cleans up the way sFlow is treated in ofproto-xlate.c, so
that the upcall cookie just contains the essential details and the
sFlow-specific encoding is migrated into ofproto-dpif-sflow.c.
Finally a new test for sFlow tunnel structures was added that exercises
the new code. So 'make check TESTSUITEFLAGS="-k sflow"' now runs
two separate tests.
One very specific question is asked in an XXX comment in ofproto-dpif.c,
regarding which lock should be acquired during the new callback. A little
guidance there would be most appreciated.
Regards,
Neil
---
lib/odp-util.c | 15 +--
lib/odp-util.h | 3 +-
lib/sflow.h | 2 +
lib/sflow_agent.c| 15 +++
lib/sflow_api.h | 1 +
lib/sflow_receiver.c | 4 +
manpages.mk | 8 +-
ofproto/ofproto-dpif-sflow.c | 250 +++
ofproto/ofproto-dpif-sflow.h | 22 ++--
ofproto/ofproto-dpif-xlate.c | 50 +++--
ofproto/ofproto-dpif.c | 38 +--
tests/odp.at | 2 +-
tests/ofproto-dpif.at| 80 ++
tests/test-sflow.c | 39 +++
14 files changed, 351 insertions(+), 178 deletions(-)
diff --git a/lib/odp-util.c b/lib/odp-util.c
index 5ca8baf..19102ad 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -296,10 +296,11 @@ format_odp_userspace_action(struct ds *ds, const struct
nlattr *attr)
if (userdata_len == sizeof cookie.sflow
&& cookie.type == USER_ACTION_COOKIE_SFLOW) {
ds_put_format(ds, ",sFlow("
- "vid=%"PRIu16",pcp=%"PRIu8",output=%"PRIu32")",
+ "vid=%"PRIu16",pcp=%"PRIu8
+ ",n_outputs=%"PRIu32",output_port=%"PRIu32")",
vlan_tci_to_vid(cookie.sflow.vlan_tci),
vlan_tci_to_pcp(cookie.sflow.vlan_tci),
- cookie.sflow.output);
+ cookie.sflow.n_outputs,cookie.sflow.output_port);
} else if (userdata_len == sizeof cookie.slow_path
&& cookie.type == USER_ACTION_COOKIE_SLOW_PATH) {
const char *reason;
@@ -507,7 +508,8 @@ parse_odp_action(const char *s, const struct simap
*port_names,
{
unsigned long long int pid;
-unsigned long long int output;
+unsigned long long int n_outputs;
+unsigned long long int output_port;
unsigned long long int probability;
unsigned long long int collector_set_id;
unsigned long long int obs_domain_id;
@@ -519,8 +521,8 @@ parse_odp_action(const char *s, const struct simap
*port_names,
odp_put_userspace_action(pid, NULL, 0, actions);
return n;
} else if (sscanf(s, "userspace(pid=%lli,sFlow(vid=%i,"
- "pcp=%i,output=%lli))%n",
- &pid, &vid, &pcp, &output, &n) > 0 && n > 0) {
+ "pcp=%i,n_outputs=%lli,output_port=%lli))%n",
+ &pid, &vid, &pcp, &n_outputs, &output_port, &n) > 0
&& n > 0) {
union user_action_cookie cookie;
uint16_t tci;
@@ -531,7 +533,8 @@ parse_odp_action(const char *s, const struct simap
*port_names,
cookie.type = USER_ACTION_COOKIE_SFLOW;
cookie.sflow.vlan_tci = htons(tci);
-cookie.sflow.output = output;
+cookie.sflow.n_outputs = n_outputs;
+cookie.sflow.output_port = output_port;
odp_put_userspace_action(pid, &cookie, sizeof cookie.sflow,
actions);
return n;
diff --git a/lib/odp-util.h b/lib/odp-util.h
index 192cfa0..2440394 100644
--- a/lib/odp-util.h
+++ b/lib/odp-util.h
@@ -156,7 +156,8 @@ union user_action_cookie {
struct {
uint16_t type; /* USER_ACTION_COOKIE_SFLOW. */
ovs_be16 vlan_tci; /* Dest
Re: [ovs-dev] [PATCH v2.42 2/5] ofp-actions: Add separate OpenFlow 1.3 action parser
On Fri, Oct 04, 2013 at 09:31:05AM -0700, Ben Pfaff wrote:
> On Fri, Oct 04, 2013 at 05:09:57PM +0900, Simon Horman wrote:
> > From: Joe Stringer
> >
> > This patch adds new ofpact_from_openflow13() and
> > ofpacts_from_openflow13() functions parallel to the existing ofpact
> > handling code. In the OpenFlow 1.3 version, push_mpls is handled
> > differently, but all other actions are handled by the existing code.
> >
> > In the case of push_mpls for OpenFlow 1.3 the new mpls_before_vlan field of
> > struct ofpact_push_mpls is set to true. This will be used by a subsequent
> > patch to allow allow the correct VLAN+MPLS datapath behaviour to be
> > determined at odp translation time.
> >
> > Signed-off-by: Joe Stringer
> > Signed-off-by: Simon Horman
>
> The need for a huge comment on mpls_before_vlan suggests to me that
> breaking it out as a separate type would be helpful. How about this:
>
> /* The position in the packet at which to insert an MPLS header.
> *
> * Used NXAST_PUSH_MPLS, OFPAT11_PUSH_MPLS. */
> enum ofpact_mpls_position {
> /* Add the MPLS LSE after the Ethernet header but before any VLAN tags.
> * OpenFlow 1.3+ requires this behavior. */
> OFPACT_MPLS_BEFORE_VLAN,
>
> /* Add the MPLS LSE after the Ethernet header and any VLAN tags.
> * OpenFlow 1.1 and 1.2 require this behavior. */
> OFPACT_MPLS_AFTER_VLAN
> };
>
> /* OFPACT_PUSH_VLAN/MPLS/PBB
> *
> * Used for NXAST_PUSH_MPLS, OFPAT11_PUSH_MPLS. */
> struct ofpact_push_mpls {
> struct ofpact ofpact;
> ovs_be16 ethertype;
> enum ofpact_mpls_position position;
> };
Hi Ben,
thanks, that looks very nice.
I will incorporate it in the next revision of the patchset.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2.42 1/5] odp: Allow VLAN actions after MPLS actions
On Fri, Oct 04, 2013 at 09:21:33AM -0700, Ben Pfaff wrote:
> On Fri, Oct 04, 2013 at 05:09:56PM +0900, Simon Horman wrote:
> > From: Joe Stringer
> >
> > OpenFlow 1.1 and 1.2, and 1.3 differ in their handling of MPLS actions in
> > the
> > presence of VLAN tags. To allow correct behaviour to be committed in
> > each situation, this patch adds a second round of VLAN tag action
> > handling to commit_odp_actions(), which occurs after MPLS actions. This
> > is implemented with a new field in 'struct xlate_in' called 'vlan_tci'.
> >
> > When an push_mpls action is composed, the flow's current VLAN state is
> > stored into xin->vlan_tci, and flow->vlan_tci is set to 0 (pop_vlan). If
> > a VLAN tag is present, it is stripped; if not, then there is no change.
> > Any later modifications to the VLAN state is written to xin->vlan_tci.
> > When committing the actions, flow->vlan_tci is used before MPLS actions,
> > and xin->vlan_tci is used afterwards. This retains the current datapath
> > behaviour, but allows VLAN actions to be applied in a more flexible
> > manner.
> >
> > Both before and after this patch MPLS LSEs are pushed onto a packet after
> > any VLAN tags that may be present. This is the behaviour described in
> > OpenFlow 1.1 and 1.2. OpenFlow 1.3 specifies that MPLS LSEs should be
> > pushed onto a packet before any VLAN tags that are present. Support
> > for this will be added by a subsequent patch that makes use of
> > the infrastructure added by this patch.
> >
> > Signed-off-by: Joe Stringer
> > Signed-off-by: Simon Horman
>
> I noticed a couple more minor points.
>
> First, it seems to me that the "vlan_tci" member that this adds to
> xlate_in could go in xlate_ctx just as well. I would prefer that,
> because (as far as I can tell) there is no reason for the client to use
> any value other than flow->vlan_tci here, and putting it in xlate_ctx
> hides it from the client.
Thanks. Yes I agree that is a good idea.
> Thanks for rearranging the code and updating the comment in
> do_xlate_actions(). It makes the operation clearer. But now that it's
> clear I have an additional question. Does it really make sense to have
> 'vlan_tci' as only a local variable in do_xlate_actions()? Presumably,
> MPLS and VLANs should interact the same way regardless of whether they
> are separated by resubmits or goto_tables. That is, I suspect that this
> is xlate_ctx state, not local state.
Agreed.
What I have done is to make an incremental patch which:
1. Moves the 'vlan_tci' member of strict xlate_in to
be the 'final_vlan_tci' member of struct xlate_ctx.
2. Moves the 'vlan_tci' local variable of do_xlate_actions()
to be the 'next_vlan_tci' member of struct xlate_ctx.
3. Restructures the comments surrounding the logic of the vlan_tci
code that this patch adds mostly as comments for the new
members of struct xlate_ctx. I hope things are (still?) clear.
For reference, the incremental patch I have so far is as follows.
I will squash it into this patch before reposting this series.
commit d57735cec0d3e53c7479725ae1cf825563902c30
Author: Simon Horman
Date: Mon Oct 7 14:30:28 2013 +0900
Move vlan state into struct xlate_ctx
1. Add final_vlan_tci member to struct xlate_ctx instead of vlan_tci member
struct xlate_xin. This seems to be a better palace for it as it does
not need to be accessible from the caller.
2. Move local vlan_tci variable of do_xlate_actions() to be the
next_vlan_tci member of strict xlate_ctx. This allows for it to work
across resubmit actions and goto table instructions.
As suggested by Ben Pfaff
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 2afd760..845c6fe 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -172,6 +172,37 @@ struct xlate_ctx {
odp_port_t sflow_odp_port; /* Output port for composing sFlow action. */
uint16_t user_cookie_offset;/* Used for user_action_cookie fixup. */
bool exit; /* No further actions should be processed. */
+
+/* The final vlan_tci state.
+ *
+ * The value of the vlan TCI prior to the committing of ODP MPLS
+ * actions should be stored in 'xin->flow->vlan_tci'.
+ *
+ * The final value of the VLAN TCI should be stored in 'vlan_tci'. And
+ * is if the value of 'vlan_tci' and 'xin->flow->vlan_tci' differ then
+ * VLAN ODP actions will be committed after any MPLS actions regardless
+ * of whether VLAN actions were also committed before the MPLS actions or
+ * not.
+ *
+ * This mechanism allows a VLAN tag to be popped before pushing
+ * an MPLS LSE and then the same VLAN tag pushed after pushing
+ * the MPLS LSE. In this way it is possible to push an MPLS LSE
+ * before an existing VLAN tag. Moreover this mechanism allows
+ * the order in which VLAN tags and MPLS LSEs are pushed. */
+ovs_be16 final_vlan_tci;
+
+/*
