Re: [ovs-dev] [PATCH 1/4] ovs-vsctl: Create AutoAttach records on demand, for backward compatibility.
Thanks for the quick fix.
Acked-by: Justin Pettit
--Justin
> On Mar 19, 2015, at 11:52 PM, Ben Pfaff wrote:
>
> The AutoAttach table is new in OVS 2.3.90, but ovs-vsctl was creating a
> record in the table unconditionally whenever it created a new bridge.
> This caused a gratuitous incompatibility with older databases, which can
> be a problem during upgrade. This commit switches to creating the
> AutoAttaach record for a bridge lazily, only when the first mapping is
> created for the bridge.
>
> VMware-BZ: #1413562
> CC: Dennis Flynn
> Reported-by: Alex Wang
> Signed-off-by: Ben Pfaff
> ---
> utilities/ovs-vsctl.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/utilities/ovs-vsctl.c b/utilities/ovs-vsctl.c
> index 1abefb4..fa73b00 100644
> --- a/utilities/ovs-vsctl.c
> +++ b/utilities/ovs-vsctl.c
> @@ -1807,7 +1807,6 @@ cmd_add_br(struct vsctl_context *ctx)
>
> if (!parent_name) {
> struct ovsrec_port *port;
> -struct ovsrec_autoattach *aa;
> struct ovsrec_bridge *br;
>
> iface = ovsrec_interface_insert(ctx->txn);
> @@ -1818,12 +1817,9 @@ cmd_add_br(struct vsctl_context *ctx)
> ovsrec_port_set_name(port, br_name);
> ovsrec_port_set_interfaces(port, &iface, 1);
>
> -aa = ovsrec_autoattach_insert(ctx->txn);
> -
> br = ovsrec_bridge_insert(ctx->txn);
> ovsrec_bridge_set_name(br, br_name);
> ovsrec_bridge_set_ports(br, &port, 1);
> -ovsrec_bridge_set_auto_attach(br, aa);
>
> ovs_insert_bridge(ctx->ovs, br);
> } else {
> @@ -2732,6 +2728,10 @@ cmd_add_aa_mapping(struct vsctl_context *ctx)
> }
>
> if (br && br->br_cfg) {
> +if (!br->br_cfg->auto_attach) {
> +struct ovsrec_autoattach *aa =
> ovsrec_autoattach_insert(ctx->txn);
> +ovsrec_bridge_set_auto_attach(br->br_cfg, aa);
> +}
> autoattach_insert_mapping(br->br_cfg->auto_attach, isid, vlan);
> }
> }
> --
> 2.1.3
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/4] ovs-vsctl: Only monitor AutoAttach columns when useful.
Thanks again for fixing this.
Acked-by: Justin Pettit
I'm only going to review these two patches tonight, since they'll fix the
upgrade issue, and it's late. I can take a look at the other two in the
morning, but let's push these when you're ready.
--Justin
> On Mar 19, 2015, at 11:52 PM, Ben Pfaff wrote:
>
> Otherwise this creates a gratuitous incompatibility with older databases,
> which can be a problem in upgrade situations.
>
> VMware-BZ: #1413562
> Reported-by: Alex Wang
> Signed-off-by: Ben Pfaff
> ---
> utilities/ovs-vsctl.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/utilities/ovs-vsctl.c b/utilities/ovs-vsctl.c
> index fa73b00..009a8ca 100644
> --- a/utilities/ovs-vsctl.c
> +++ b/utilities/ovs-vsctl.c
> @@ -1185,7 +1185,6 @@ pre_get_info(struct vsctl_context *ctx)
> ovsdb_idl_add_column(ctx->idl, &ovsrec_bridge_col_controller);
> ovsdb_idl_add_column(ctx->idl, &ovsrec_bridge_col_fail_mode);
> ovsdb_idl_add_column(ctx->idl, &ovsrec_bridge_col_ports);
> -ovsdb_idl_add_column(ctx->idl, &ovsrec_bridge_col_auto_attach);
>
> ovsdb_idl_add_column(ctx->idl, &ovsrec_port_col_name);
> ovsdb_idl_add_column(ctx->idl, &ovsrec_port_col_fake_bridge);
> @@ -1194,7 +1193,6 @@ pre_get_info(struct vsctl_context *ctx)
>
> ovsdb_idl_add_column(ctx->idl, &ovsrec_interface_col_name);
>
> -ovsdb_idl_add_column(ctx->idl, &ovsrec_autoattach_col_mappings);
> ovsdb_idl_add_column(ctx->idl, &ovsrec_interface_col_ofport);
> }
>
> @@ -2806,6 +2804,7 @@ pre_aa_mapping(struct vsctl_context *ctx)
> {
> pre_get_info(ctx);
>
> +ovsdb_idl_add_column(ctx->idl, &ovsrec_bridge_col_auto_attach);
> ovsdb_idl_add_column(ctx->idl, &ovsrec_autoattach_col_mappings);
> }
>
> @@ -4678,7 +4677,7 @@ static const struct vsctl_command_syntax all_commands[]
> = {
> cmd_set_ssl, NULL, "--bootstrap", RW},
>
> /* Auto Attach commands. */
> -{"add-aa-mapping", 3, 3, "BRIDGE ARG ARG", pre_get_info,
> cmd_add_aa_mapping,
> +{"add-aa-mapping", 3, 3, "BRIDGE ARG ARG", pre_aa_mapping,
> cmd_add_aa_mapping,
> NULL, "", RW},
> {"del-aa-mapping", 3, 3, "BRIDGE ARG ARG", pre_aa_mapping,
> cmd_del_aa_mapping,
> NULL, "", RW},
> --
> 2.1.3
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/4] ovs-vsctl: Only monitor AutoAttach columns when useful.
Thanks for these two reviews. I applied these to master.
On Fri, Mar 20, 2015 at 12:15:54AM -0700, Justin Pettit wrote:
> Thanks again for fixing this.
>
> Acked-by: Justin Pettit
>
> I'm only going to review these two patches tonight, since they'll fix the
> upgrade issue, and it's late. I can take a look at the other two in the
> morning, but let's push these when you're ready.
>
> --Justin
>
>
> > On Mar 19, 2015, at 11:52 PM, Ben Pfaff wrote:
> >
> > Otherwise this creates a gratuitous incompatibility with older databases,
> > which can be a problem in upgrade situations.
> >
> > VMware-BZ: #1413562
> > Reported-by: Alex Wang
> > Signed-off-by: Ben Pfaff
> > ---
> > utilities/ovs-vsctl.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/utilities/ovs-vsctl.c b/utilities/ovs-vsctl.c
> > index fa73b00..009a8ca 100644
> > --- a/utilities/ovs-vsctl.c
> > +++ b/utilities/ovs-vsctl.c
> > @@ -1185,7 +1185,6 @@ pre_get_info(struct vsctl_context *ctx)
> > ovsdb_idl_add_column(ctx->idl, &ovsrec_bridge_col_controller);
> > ovsdb_idl_add_column(ctx->idl, &ovsrec_bridge_col_fail_mode);
> > ovsdb_idl_add_column(ctx->idl, &ovsrec_bridge_col_ports);
> > -ovsdb_idl_add_column(ctx->idl, &ovsrec_bridge_col_auto_attach);
> >
> > ovsdb_idl_add_column(ctx->idl, &ovsrec_port_col_name);
> > ovsdb_idl_add_column(ctx->idl, &ovsrec_port_col_fake_bridge);
> > @@ -1194,7 +1193,6 @@ pre_get_info(struct vsctl_context *ctx)
> >
> > ovsdb_idl_add_column(ctx->idl, &ovsrec_interface_col_name);
> >
> > -ovsdb_idl_add_column(ctx->idl, &ovsrec_autoattach_col_mappings);
> > ovsdb_idl_add_column(ctx->idl, &ovsrec_interface_col_ofport);
> > }
> >
> > @@ -2806,6 +2804,7 @@ pre_aa_mapping(struct vsctl_context *ctx)
> > {
> > pre_get_info(ctx);
> >
> > +ovsdb_idl_add_column(ctx->idl, &ovsrec_bridge_col_auto_attach);
> > ovsdb_idl_add_column(ctx->idl, &ovsrec_autoattach_col_mappings);
> > }
> >
> > @@ -4678,7 +4677,7 @@ static const struct vsctl_command_syntax
> > all_commands[] = {
> > cmd_set_ssl, NULL, "--bootstrap", RW},
> >
> > /* Auto Attach commands. */
> > -{"add-aa-mapping", 3, 3, "BRIDGE ARG ARG", pre_get_info,
> > cmd_add_aa_mapping,
> > +{"add-aa-mapping", 3, 3, "BRIDGE ARG ARG", pre_aa_mapping,
> > cmd_add_aa_mapping,
> > NULL, "", RW},
> > {"del-aa-mapping", 3, 3, "BRIDGE ARG ARG", pre_aa_mapping,
> > cmd_del_aa_mapping,
> > NULL, "", RW},
> > --
> > 2.1.3
> >
> > ___
> > dev mailing list
> > dev@openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Returned mail: see transcript for details
Dear user dev@openvswitch.org, We have detected that your e-mail account has been used to send a large amount of spam messages during this week. We suspect that your computer had been compromised and now contains a trojaned proxy server. We recommend you to follow our instructions in order to keep your computer safe. Best wishes, The openvswitch.org team. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 1/4] ovs-vsctl: Create AutoAttach records on demand, for backward compatibility.
Thanks for fixing this.
Acked-by: Dennis Flynn
-Original Message-
From: Ben Pfaff [mailto:b...@nicira.com]
Sent: Friday, March 20, 2015 2:53 AM
To: dev@openvswitch.org
Cc: Ben Pfaff; Flynn, Dennis R (Dennis); Alex Wang
Subject: [PATCH 1/4] ovs-vsctl: Create AutoAttach records on demand, for
backward compatibility.
The AutoAttach table is new in OVS 2.3.90, but ovs-vsctl was creating a record
in the table unconditionally whenever it created a new bridge.
This caused a gratuitous incompatibility with older databases, which can be a
problem during upgrade. This commit switches to creating the AutoAttaach
record for a bridge lazily, only when the first mapping is created for the
bridge.
VMware-BZ: #1413562
CC: Dennis Flynn
Reported-by: Alex Wang
Signed-off-by: Ben Pfaff
---
utilities/ovs-vsctl.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/utilities/ovs-vsctl.c b/utilities/ovs-vsctl.c index
1abefb4..fa73b00 100644
--- a/utilities/ovs-vsctl.c
+++ b/utilities/ovs-vsctl.c
@@ -1807,7 +1807,6 @@ cmd_add_br(struct vsctl_context *ctx)
if (!parent_name) {
struct ovsrec_port *port;
-struct ovsrec_autoattach *aa;
struct ovsrec_bridge *br;
iface = ovsrec_interface_insert(ctx->txn);
@@ -1818,12 +1817,9 @@ cmd_add_br(struct vsctl_context *ctx)
ovsrec_port_set_name(port, br_name);
ovsrec_port_set_interfaces(port, &iface, 1);
-aa = ovsrec_autoattach_insert(ctx->txn);
-
br = ovsrec_bridge_insert(ctx->txn);
ovsrec_bridge_set_name(br, br_name);
ovsrec_bridge_set_ports(br, &port, 1);
-ovsrec_bridge_set_auto_attach(br, aa);
ovs_insert_bridge(ctx->ovs, br);
} else {
@@ -2732,6 +2728,10 @@ cmd_add_aa_mapping(struct vsctl_context *ctx)
}
if (br && br->br_cfg) {
+if (!br->br_cfg->auto_attach) {
+struct ovsrec_autoattach *aa = ovsrec_autoattach_insert(ctx->txn);
+ovsrec_bridge_set_auto_attach(br->br_cfg, aa);
+}
autoattach_insert_mapping(br->br_cfg->auto_attach, isid, vlan);
}
}
--
2.1.3
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 0/6] DPDK: simplify configuration
> On 19 Mar 2015, at 18:34, Gray, Mark D wrote: > >> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Gray, Mark >> D >> Sent: Thursday, March 19, 2015 6:19 PM >> To: Traynor, Kevin; Daniele Di Proietto >> Subject: Re: [ovs-dev] [PATCH 0/6] DPDK: simplify configuration >> >> [snip] > > Hi, I've reviewed this patchset - few comments/questions on it… Hi Kevin, thanks > I haven't tested yet - but I'm wondering what is the impact to the > dpdk -c parameter. Is it no longer used for OVS? > Yes, that’s correct. It should have no impact on OVS. I think we should also provide a default, i.e. generate the parameters passed to dpdk_eal_init at some point. >> >> +1 to removing the -c parameter as it seems to be the same as >> 'other_config:n-pmd-cores' and is a little confusing as to how they interact. >> Maybe 'other_config:n-pmd-cores' could be a mandatory option? > > I used the wrong config option in above. Let me rephrase it. > +1 to removing the -c parameter as it seems to be the same as > 'other_config:pmd-cpu-mask + other_config:nonpmd-cpu-mask' and is a little > confusing as to how they interact. > Maybe 'other_config:pmd-cpu-mask + other_config:nonpmd-cpu-mask' could be a > mandatory option? The idea behind this change is to let advanced users configure their masks, and provide a simple configuration parameter (n-pmd-cores) for users who do not want or need to deal with cpu masks. What do you think? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 1/2] acinclude.m4: Restore --whole-archive option for DPDK.
The --whole-archive option is required to link vswitchd with DPDK, otherwise the PMD drivers are not going to be included. Omitting the option is not going to cause build failures, but OVS won't be able to use most physical NICs. Signed-off-by: Daniele Di Proietto --- acinclude.m4 | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/acinclude.m4 b/acinclude.m4 index a56d160..d4a3133 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -170,7 +170,8 @@ AC_DEFUN([OVS_CHECK_DPDK], [ DPDK_INCLUDE=$RTE_SDK/include DPDK_LIB_DIR=$RTE_SDK/lib -DPDK_LIB="-lintel_dpdk -lfuse " +DPDK_LIB="-lintel_dpdk" +DPDK_EXTRA_LIB="-lfuse" ovs_save_CFLAGS="$CFLAGS" ovs_save_LDFLAGS="$LDFLAGS" @@ -187,7 +188,7 @@ AC_DEFUN([OVS_CHECK_DPDK], [ found=false save_LIBS=$LIBS for extras in "" "-ldl"; do -LIBS="$DPDK_LIB $extras $save_LIBS" +LIBS="$DPDK_LIB $extras $save_LIBS $DPDK_EXTRA_LIB" AC_LINK_IFELSE( [AC_LANG_PROGRAM([#include #include ], @@ -214,7 +215,7 @@ AC_DEFUN([OVS_CHECK_DPDK], [ # # These options are specified inside a single -Wl directive to prevent # autotools from reordering them. -DPDK_vswitchd_LDFLAGS=-Wl,$DPDK_LIB +DPDK_vswitchd_LDFLAGS=-Wl,--whole-archive,$DPDK_LIB,--no-whole-archive AC_SUBST([DPDK_vswitchd_LDFLAGS]) AC_DEFINE([DPDK_NETDEV], [1], [System uses the DPDK module.]) else -- 2.1.4 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 2/2] DPDK: Update documentation and travis build for vhost.
DPDK vhost support is mandatory to compile OVS with DPDK. This commit
updates INSTALL.DPDK.md and the travis build procedure to reflect that.
Signed-off-by: Daniele Di Proietto
---
Or we could make vhost support optional in netdev-dpdk.c
What do you guys think?
---
.travis/build.sh | 1 +
.travis/prepare.sh | 3 +++
INSTALL.DPDK.md| 21 +
3 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/.travis/build.sh b/.travis/build.sh
index 942265a..b6b701c 100755
--- a/.travis/build.sh
+++ b/.travis/build.sh
@@ -48,6 +48,7 @@ function install_dpdk()
fi
find ./ -type f | xargs sed -i
's/max-inline-insns-single=100/max-inline-insns-single=400/'
sed -ri 's,(CONFIG_RTE_BUILD_COMBINE_LIBS=).*,\1y,' config/common_linuxapp
+sed -ri 's,(CONFIG_RTE_LIBRTE_VHOST=).*,\1y,' config/common_linuxapp
sed -ri '/CONFIG_RTE_LIBNAME/a CONFIG_RTE_BUILD_FPIC=y'
config/common_linuxapp
sed -ri '/EXECENV_CFLAGS = -pthread -fPIC/{s/$/\nelse ifeq
($(CONFIG_RTE_BUILD_FPIC),y)/;s/$/\nEXECENV_CFLAGS = -pthread -fPIC/}'
mk/exec-env/linuxapp/rte.vars.mk
make config CC=gcc T=x86_64-native-linuxapp-gcc
diff --git a/.travis/prepare.sh b/.travis/prepare.sh
index a78282b..cda80c2 100755
--- a/.travis/prepare.sh
+++ b/.travis/prepare.sh
@@ -3,6 +3,9 @@
sudo apt-get update -qq
sudo apt-get install -qq libssl-dev llvm-dev
sudo apt-get install -qq gcc-multilib
+if [ "$DPDK" ]; then
+sudo apt-get install -qq libfuse-dev
+fi
git clone git://git.kernel.org/pub/scm/devel/sparse/chrisl/sparse.git
cd sparse && make && sudo make install PREFIX=/usr && cd ..
diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md
index a3e2a1d..5b61272 100644
--- a/INSTALL.DPDK.md
+++ b/INSTALL.DPDK.md
@@ -16,8 +16,7 @@ OVS needs a system with 1GB hugepages support.
Building and Installing:
-Required DPDK 1.8.0
-Optional `fuse`, `fuse-devel`
+Required DPDK 1.8.0, `fuse`, `fuse-devel` (`libfuse-dev` on Debian/Ubuntu)
1. Configure build & install DPDK:
1. Set `$DPDK_DIR`
@@ -32,7 +31,12 @@ Optional `fuse`, `fuse-devel`
`CONFIG_RTE_BUILD_COMBINE_LIBS=y`
- Then run `make install` to build and isntall the library.
+ Update `config/common_linuxapp` so that DPDK is built with vhost
+ libraries:
+
+ `CONFIG_RTE_LIBRTE_VHOST=y`
+
+ Then run `make install` to build and install the library.
For default install without IVSHMEM:
`make install T=x86_64-native-linuxapp-gcc`
@@ -300,18 +304,11 @@ in future releases when supported in DPDK and that
vhost-cuse will eventually
be deprecated. See [DPDK Docs] for more info on vhost.
Prerequisites:
-1. DPDK 1.8 with vhost support enabled and recompile OVS as above.
-
- Update `config/common_linuxapp` so that DPDK is built with vhost
- libraries:
-
- `CONFIG_RTE_LIBRTE_VHOST=y`
-
-2. Insert the Cuse module:
+1. Insert the Cuse module:
`modprobe cuse`
-3. Build and insert the `eventfd_link` module:
+2. Build and insert the `eventfd_link` module:
`cd $DPDK_DIR/lib/librte_vhost/eventfd_link/`
`make`
--
2.1.4
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Costumoized actions
Hello!
At the end I could make it work. I followed the steps of the actions
regarding ARP. I changed where to perform the commit_action function and
moved it to commit_set_nw_action. Now works perfectly. I do not know what
behaviour changes perform this change I did, but the thing that matters is
that it works now.
Kind regards and thank you for your help,
Raúl Suárez
2015-03-19 22:14 GMT+00:00 Jarno Rajahalme :
> Any custom actions need to be supported by the datapaths, otherwise they
> fail flow setup validation. Linux datapath (kernel module) is part of the
> linux kernel sources, but if you need to try out something you can test
> your feature with the userspace datapath first, then maybe with the
> ova-tree linux kernel module in the datapath directory.
>
> However, if you are adding support for a new packet header field (as
> hinted by MY_FIELD), you should not need to implement any new actions, as
> you should be able to use the set_field action.
>
> Jarno
>
>
> On Mar 19, 2015, at 2:38 PM, Raul Suarez Marin <
> raul.suarez.ma...@gmail.com> wrote:
>
> Thanks Jarno for the hints!
>
> I found this function looking for ", struct dpif_op " term in every file.
>
> static void dpif_linux_operate(struct dpif *dpif_, struct dpif_op **ops,
> size_t n_ops)
>
> The main lines in that function of my interest are:
> dpif_linux_encode_execute(dpif->dp_ifindex, execute, &aux->request);
> nl_transact_multiple(NETLINK_GENERIC, txnsp, n_ops);
>
> As I understand from this function, and following the path for op->type
> = DPIF_OP_EXECUTE, a request is sent at
> "nl_transact_multiple(NETLINK_GENERIC, txnsp, n_ops);" through
> NETLINK_GENERIC protocol (to the kernel?, any hint to where are they
> sent?). Inside this function, I can find these important functions:
>
> lib/netlink-socket.c:
> nl_sock_transact_multiple__(struct nl_sock *sock,
> struct nl_transaction **transactions, size_t n,
> size_t *done) {
> /* some lines */
> do {
> error = sendmsg(sock->fd, &msg, 0) < 0 ? errno : 0;
> } while (error == EINTR);
>
> /* some lines */
>
> error = nl_sock_recv__(sock, buf_txn->reply, false);
>
> /* some lines */
>
> The thing is that when my action is performed, the error value is 0 (BAD,
> packet is not sent); and when it is not performed, error = 11 = EAGAIN (OK,
> actions are performed and packet is sent). I guess this means that whoever
> receives the request, still does not understand the meaning of the custom
> action I am creating.
>
> I will be posting here any updates I have.
>
> Kind regards,
> Raúl Suárez
>
>
> 2015-03-19 20:50 GMT+01:00 Jarno Rajahalme :
>
>> Raúl,
>>
>> The dip class functions are implemented by the different dip classes.
>> Linux and Windows data paths are interfaced by lib/dpif-netlink.c and the
>> userspace datapath is implemented in lib/dpif-netlink.c. You’ll find a
>> class struct with the local function pointers in those files, just search
>> for “operate” in those files.
>>
>> Hope this helps,
>>
>> Jarno
>>
>> > On Mar 19, 2015, at 2:06 AM, Raul Suarez Marin <
>> raul.suarez.ma...@gmail.com> wrote:
>> >
>> > Hello again,
>> >
>> > At lib/dpif.c in function "dpif_operate" there is a line that is being
>> > called.
>> > dpif->dpif_class->operate(dpif, ops, chunk);
>> >
>> > This is possibly the actions are performed, but I have no clue how to
>> know
>> > what function this line leads to.
>> >
>> > In lib/dpif-provider.h I can find the definition for these structs, but
>> I
>> > can only see:
>> >
>> > /* Executes each of the 'n_ops' operations in 'ops' on 'dpif', in the
>> order
>> > * in which they are specified, placing each operation's results in the
>> > * "output" members documented in comments.
>> > *
>> > * This function is optional. It is only worthwhile to implement it if
>> > * 'dpif' can perform operations in batch faster than individually. */
>> > void (*operate)(struct dpif *dpif, struct dpif_op **ops, size_t n_ops);
>> >
>> > Kind regards,
>> > Raúl Suárez
>> >
>> > 2015-03-18 21:26 GMT+01:00 Raul Suarez Marin <
>> raul.suarez.ma...@gmail.com>:
>> >
>> >> Hello Ben,
>> >>
>> >> Thank you for your answer. Let me correct myself when I said I adapated
>> >> parts of "handle_upcalls", I realized I just added debugging lines only
>> >> (my bad).
>> >> I am trying to do the ovs-vswitchd ofproto/trace command but I am
>> getting
>> >> failed connection attempts because "address family is not supported by
>> >> protocol". I will sort it out.
>> >>
>> >> My thoughts right now are:
>> >> 1) I have done in "do_xlate_actions" the part of reading the field I
>> want
>> >> to apply the action to. (new case OFPACT_MY_FIELD)
>> >> 2) I adapted "commit_odp_actions" which is called
>> >> by "compose_output_action" which is called by "xlate_output_action"
>> which
>> >> is called by "do_xlate_actions" (case OFPACT_OUTPUT) and it is located
>> in
>> >> "lib/ofp-util.c" This function adds the actions to the ofpbuf at
>> c
Re: [ovs-dev] These words make chicks horny?
Do you know how to make any girl horny for you? This Video Shows You How http://x.co/8CDEt Just watch the video, use the tips, and start banging between 5 and 7 girls every week. If you want to use the tips to get a loyal dedicated girlfriend, you can use it for that too. And when you use this trick, there is no chance of rejection. So if you've ever been scared of "making your move" then this is for you. Watch The Video Now This video comes down tonight at midnight. So this is your only chance to watch. Go ahead and... Watch The Video Now http://x.co/8CCxh And discover how to make any woman want to bang ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/2] DPDK: Update documentation and travis build for vhost.
On Fri, Mar 20, 2015 at 6:02 AM, Daniele Di Proietto wrote: > DPDK vhost support is mandatory to compile OVS with DPDK. This commit > updates INSTALL.DPDK.md and the travis build procedure to reflect that. > > Signed-off-by: Daniele Di Proietto > --- > Or we could make vhost support optional in netdev-dpdk.c > What do you guys think? I think we should always build it. Thanks for both patches. I pushed those to master. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/2] DPDK: Update documentation and travis build for vhost.
> On 20 Mar 2015, at 17:02, Pravin Shelar wrote: > > On Fri, Mar 20, 2015 at 6:02 AM, Daniele Di Proietto > wrote: >> DPDK vhost support is mandatory to compile OVS with DPDK. This commit >> updates INSTALL.DPDK.md and the travis build procedure to reflect that. >> >> Signed-off-by: Daniele Di Proietto >> --- >> Or we could make vhost support optional in netdev-dpdk.c >> What do you guys think? > > I think we should always build it. > > Thanks for both patches. I pushed those to master. Ok, thanks! ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] datapath-windows: Solved BSOD when uninstalling the driver (race condition)
The BSOD occurred because the FilterAttach routine released the switch
context, while there were IRPs in processing.
The solution was to add a reference count in the switch context to prevent
premature deallocation of the switch context structure.
Signed-off-by: Sorin Vinturis
Reported-by: Alin Gabriel Serdean
Reported-at: https://github.com/openvswitch/ovs-issues/issues/58
---
datapath-windows/ovsext/Datapath.c | 10 +
datapath-windows/ovsext/Switch.c | 44 ++
datapath-windows/ovsext/Switch.h | 12 ++-
3 files changed, 61 insertions(+), 5 deletions(-)
diff --git a/datapath-windows/ovsext/Datapath.c
b/datapath-windows/ovsext/Datapath.c
index 8eb13f1..8b561a3 100644
--- a/datapath-windows/ovsext/Datapath.c
+++ b/datapath-windows/ovsext/Datapath.c
@@ -699,10 +699,9 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
outputBufferLen = irpSp->Parameters.DeviceIoControl.OutputBufferLength;
inputBuffer = irp->AssociatedIrp.SystemBuffer;
-/* Check if the extension is enabled. */
-if (NULL == gOvsSwitchContext) {
-status = STATUS_DEVICE_NOT_READY;
-goto done;
+if (!OvsAcquireSwitchContext(gOvsSwitchContext)) {
+status = STATUS_NOT_FOUND;
+goto exit;
}
/* Concurrent netlink operations are not supported. */
@@ -874,6 +873,9 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
status = InvokeNetlinkCmdHandler(&usrParamsCtx, nlFamilyOps, &replyLen);
done:
+OvsReleaseSwitchContext(gOvsSwitchContext);
+
+exit:
KeMemoryBarrier();
instance->inUse = 0;
diff --git a/datapath-windows/ovsext/Switch.c b/datapath-windows/ovsext/Switch.c
index a228d8e..8366944 100644
--- a/datapath-windows/ovsext/Switch.c
+++ b/datapath-windows/ovsext/Switch.c
@@ -420,6 +420,9 @@ OvsInitSwitchContext(POVS_SWITCH_CONTEXT switchContext)
switchContext->isActivateFailed = FALSE;
switchContext->dpNo = OVS_DP_NUMBER;
ovsTimeIncrementPerTick = KeQueryTimeIncrement() / 1;
+
+switchContext->refCount = 1;
+
OVS_LOG_TRACE("Exit: Succesfully initialized switchContext: %p",
switchContext);
return NDIS_STATUS_SUCCESS;
@@ -428,6 +431,12 @@ OvsInitSwitchContext(POVS_SWITCH_CONTEXT switchContext)
static VOID
OvsUninitSwitchContext(POVS_SWITCH_CONTEXT switchContext)
{
+OvsReleaseSwitchContext(switchContext);
+}
+
+VOID
+OvsDeleteSwitchContext(POVS_SWITCH_CONTEXT switchContext)
+{
OVS_LOG_TRACE("Enter: Delete switchContext:%p", switchContext);
/* We need to do cleanup for tunnel port here. */
@@ -447,9 +456,44 @@ OvsUninitSwitchContext(POVS_SWITCH_CONTEXT switchContext)
switchContext->pidHashArray = NULL;
OvsDeleteFlowTable(&switchContext->datapath);
OvsCleanupBufferPool(switchContext);
+switchContext->refCount = 0;
OVS_LOG_TRACE("Exit: Delete switchContext: %p", switchContext);
}
+VOID
+OvsReleaseSwitchContext(POVS_SWITCH_CONTEXT switchContext)
+{
+if (1 == InterlockedCompareExchange(
+(LONG volatile *)&switchContext->refCount, 0, 1)) {
+OvsDeleteSwitchContext(switchContext);
+}
+else {
+InterlockedDecrement((LONG volatile *)&switchContext->refCount);
+}
+}
+
+BOOLEAN
+OvsAcquireSwitchContext(POVS_SWITCH_CONTEXT switchContext)
+{
+BOOLEAN ret = FALSE;
+
+do {
+if (NULL == switchContext) {
+break;
+}
+
+if (0 == InterlockedCompareExchange(
+(LONG volatile *)&switchContext->refCount, 0, 0)) {
+break;
+}
+
+InterlockedIncrement((LONG volatile *)&switchContext->refCount);
+ret = TRUE;
+} while (!ret);
+
+return ret;
+}
+
/*
* --
* This function activates the switch by initializing it with all the runtime
diff --git a/datapath-windows/ovsext/Switch.h b/datapath-windows/ovsext/Switch.h
index 7960072..25db636 100644
--- a/datapath-windows/ovsext/Switch.h
+++ b/datapath-windows/ovsext/Switch.h
@@ -179,6 +179,12 @@ typedef struct _OVS_SWITCH_CONTEXT
volatile LONG pendingOidCount;
OVS_NBL_POOLovsPool;
+
+/*
+ * Reference count used to prevent premature deallocation of the switch
+ * context.
+ */
+INT32 refCount;
} OVS_SWITCH_CONTEXT, *POVS_SWITCH_CONTEXT;
@@ -202,7 +208,6 @@ OvsAcquireDatapathWrite(OVS_DATAPATH *datapath,
dispatch ? NDIS_RWL_AT_DISPATCH_LEVEL : 0);
}
-
static __inline VOID
OvsReleaseDatapath(OVS_DATAPATH *datapath,
LOCK_STATE_EX *lockState)
@@ -211,6 +216,11 @@ OvsReleaseDatapath(OVS_DATAPATH *datapath,
NdisReleaseRWLock(datapath->lock, lockState);
}
+BOOLEAN
+OvsAcquireSwitchContext(POVS_SWITCH_CONTEXT switchContext);
+
+VOID
+OvsReleaseSwitchContext(POVS_SWITCH_CONTEXT switchContext);
PVOID OvsGetExternalVport();
--
1.9.0.msysgit.0
___
Re: [ovs-dev] [PATCH 2/2] DPDK: Update documentation and travis build for vhost.
> -Original Message- > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Daniele Di > Proietto > Sent: Friday, March 20, 2015 5:25 PM > To: Pravin Shelar > Cc: dev@openvswitch.org > Subject: Re: [ovs-dev] [PATCH 2/2] DPDK: Update documentation and travis > build for vhost. > > > > On 20 Mar 2015, at 17:02, Pravin Shelar wrote: > > > > On Fri, Mar 20, 2015 at 6:02 AM, Daniele Di Proietto > > wrote: > >> DPDK vhost support is mandatory to compile OVS with DPDK. This commit > >> updates INSTALL.DPDK.md and the travis build procedure to reflect that. > >> > >> Signed-off-by: Daniele Di Proietto > >> --- > >> Or we could make vhost support optional in netdev-dpdk.c > >> What do you guys think? > > > > I think we should always build it. > > > > Thanks for both patches. I pushed those to master. > > Ok, thanks! Thanks for these Daniele ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH RFC 1/1] netdev-dpdk: add dpdk vhost-user ports
On Thu, Mar 19, 2015 at 11:48 AM, Ciara Loftus wrote: > This patch adds support for a new port type to the userspace datapath > called dpdkvhostuser. It adds to the existing infrastructure of > vhost-cuse, however disables vhost-cuse ports in favour of vhost-user > ports. > > A new dpdkvhostuser port will create a unix domain socket which when > provided to QEMU is used to facilitate communication between the > virtio-net device on the VM and the OVS port. > Thanks for the patch. I have pushed OVS DPDK vHost cuse patch. Once we add support for vhost user, vhost-cuse support should be dropped. I think we need to wait for dpdk 2.0 for vhost-user support. So can you post rebased patch once we move to DPDK 2.0? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH v2] ovn: add start of ovn-nbctl
ovn-nbctl is intended to be a utility for manually interacting with the OVN northbound db. A real consumer of OVN, such as OpenStack, should be using ovsdb directly. However, a utility like this is useful during development and testing of both ovn itself as well as the OpenStack Neutron plugin. It could also be used when debugging the state of an ovn deployment. So far, the commands related to logical switches have been implemented. You can add, delete, list, and get/set external:ids. Signed-off-by: Russell Bryant --- ovn/.gitignore | 2 + ovn/automake.mk | 8 +- ovn/ovn-nbctl.8.xml | 22 ovn/ovn-nbctl.c | 338 4 files changed, 368 insertions(+), 2 deletions(-) diff --git a/ovn/.gitignore b/ovn/.gitignore index 011bb1c..f320a6b 100644 --- a/ovn/.gitignore +++ b/ovn/.gitignore @@ -12,3 +12,5 @@ /ovn-nb-idl.c /ovn-nb-idl.h /ovn-nb-idl.ovsidl +/ovn-nbctl +/ovn-nbctl.8 diff --git a/ovn/automake.mk b/ovn/automake.mk index cc1f8ae..37b0ca6 100644 --- a/ovn/automake.mk +++ b/ovn/automake.mk @@ -66,8 +66,8 @@ ovn/ovn-nb.5: \ $(srcdir)/ovn/ovn-nb.xml > $@.tmp && \ mv $@.tmp $@ -man_MANS += ovn/ovn-controller.8 ovn/ovn-architecture.7 -EXTRA_DIST += ovn/ovn-controller.8.in ovn/ovn-architecture.7.xml +man_MANS += ovn/ovn-controller.8 ovn/ovn-architecture.7 ovn/ovn-nbctl.8 +EXTRA_DIST += ovn/ovn-controller.8.in ovn/ovn-architecture.7.xml ovn/ovn-nbctl.8.xml SUFFIXES += .xml %: %.xml @@ -115,3 +115,7 @@ ovn_libovn_la_SOURCES = \ ovn/ovn-idl.h \ ovn/ovn-nb-idl.c \ ovn/ovn-nb-idl.h + +bin_PROGRAMS += ovn/ovn-nbctl +ovn_ovn_nbctl_SOURCES = ovn/ovn-nbctl.c +ovn_ovn_nbctl_LDADD = ovn/libovn.la ovsdb/libovsdb.la lib/libopenvswitch.la diff --git a/ovn/ovn-nbctl.8.xml b/ovn/ovn-nbctl.8.xml new file mode 100644 index 000..beccb79 --- /dev/null +++ b/ovn/ovn-nbctl.8.xml @@ -0,0 +1,22 @@ + + +Name +ovn-nbctl -- Open Virtual Network northbound db management utility + +Synopsys +ovn-nbctl [OPTIONS] COMMAND [ARG...] + +Description +This utility can be used to manage the OVN northbound database. + +Commands +lswitch-add [name] +lswitch-del+lswitch-list +lswitch-set-external-id [value] +lswitch-get-external-id [key] + +Options +-h | --help +-V | --version + diff --git a/ovn/ovn-nbctl.c b/ovn/ovn-nbctl.c new file mode 100644 index 000..64522bf --- /dev/null +++ b/ovn/ovn-nbctl.c @@ -0,0 +1,338 @@ +/* + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at: + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +#include + +#include +#include +#include + +#include "command-line.h" +#include "dirs.h" +#include "fatal-signal.h" +#include "ovn/ovn-nb-idl.h" +#include "poll-loop.h" +#include "util.h" +#include "openvswitch/vlog.h" + +struct nbctl_context { +struct ovsdb_idl *idl; +struct ovsdb_idl_txn *txn; +const char *db; +}; + +static const struct ovs_cmdl_command *get_all_commands(void); + +static void +usage(void) +{ +printf("\ +%s: OVN northbound DB management utility\n\ +usage: %s [OPTIONS] COMMAND [ARG...]\n\ +\n\ +Commands:\n\ + lswitch-add [name]Create a logical switch\n\ + lswitch-del Delete a logical switch\n\ + lswitch-list List configured logical switches\n\ + lswitch-set-external-id [value]\n\ +Set or delete an external:id on a logical switch\n\ + lswitch-get-external-id [key]\n\ +List one or all external:ids set on a switch\n\ +Options:\n\ + -h, --helpdisplay this help message\n\ + -o, --options list available options\n\ + -V, --version display version information\n\ +", program_name, program_name); +} + +static const char * +default_db(void) +{ +static char *db; +if (!db) { +db = xasprintf("unix:%s/db.sock", ovs_rundir()); +} +return db; +} + +static const struct nbrec_logical_switch * +lswitch_by_name_or_uuid(struct nbctl_context *nb_ctx, const char *id) +{ +const struct nbrec_logical_switch *lswitch = NULL; +int is_uuid = 0; +int duplicate = 0; +struct uuid lswitch_uuid; + +if (uuid_from_string(&lswitch_uuid, id)) { +is_uuid = 1; +lswitch = nbrec_logical_switch_get_for_uuid(nb_ctx->idl, &lswitch_uuid); +} else { +const struct nbrec_logical_switch *iter; + +NBREC_LOGICAL_SWITCH_FOR_EACH(iter, nb_ct
[ovs-dev] really needs help. Thank you
Hello.
I am trying to print a message (e.g. by printk("something")) for each
processed packet by OVS, so I modified the ./datapath/datapath.c file in
the function of ovs_dp_process_received_packet(struct vport *p, struct
sk_buff *skb).
Then I recompile everything by "fakeroot debian/rules binary" to generate
new .deb files. and re-install:
openvswitch-common,
openvswitch-pki,
openvswitch-switch
openvswitch-datapath-dkms
However, I can not find my message(e.g. "something") by dmesg after I
generate some packets, although new flow entry was also successfully
created..
I also tried to configure/make module_install and then "insmod
openvswitch.ko" manually, it also does not work to see "something" message
by dmesg..
Could you please give me some help?
Thank you so much
cui
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn: Design and Schema changes for Container integration.
On 03/19/2015 10:31 AM, Gurucharan Shetty wrote: > The design was come up after inputs and discussions with multiple > people, including (in alphabetical order) Aaron Rosen, Ben Pfaff, > Ganesan Chandrashekhar, Justin Pettit, Russell Bryant and Somik Behera. > > Signed-off-by: Gurucharan Shetty > --- > ovn/CONTAINERS.OpenStack.md | 114 ++ > ovn/automake.mk |4 +- > ovn/ovn-architecture.7.xml | 186 > ++- > ovn/ovn-nb.ovsschema|6 ++ > ovn/ovn-nb.xml | 49 ++-- > ovn/ovn.ovsschema |6 ++ > ovn/ovn.xml | 58 ++ > 7 files changed, 380 insertions(+), 43 deletions(-) > create mode 100644 ovn/CONTAINERS.OpenStack.md > > diff --git a/ovn/CONTAINERS.OpenStack.md b/ovn/CONTAINERS.OpenStack.md > new file mode 100644 > index 000..58b5588 > --- /dev/null > +++ b/ovn/CONTAINERS.OpenStack.md > @@ -0,0 +1,114 @@ > +Integration of Containers with OVN and OpenStack > + > + > +In a multi-tenant environment, creating containers directly on hypervisors > +has many risks. A container application can break out and make changes to > +the Open vSwitch flows and thus impact other tenants. This document > +describes creation of containers inside VMs and how they can be made part > +of the logical networks securely. The created logical network can include > VMs, > +containers and physical machines as endpoints. To better understand the > +proposed integration of containers with OVN and OpenStack, this document > +describes the end to end workflow with an example. > + > +* A OpenStack tenant creates a VM (say VM-A) with a single network interface > +that belongs to a management logical network. The VM is meant to host > +containers. OpenStack Nova chooses the hypervisor on which VM-A is created. > + > +* A Neutron port may have been created in advance and passed in to Nova > +with the request to create a new VM. If not, Nova will issue a request > +to Neutron to create a new port. The ID of the logical port from > +Neutron will also be used as the vif-id for the virtual network > +interface (VIF) of VM-A. > + > +* When VM-A is created on a hypervisor, its VIF gets added to the > +Open vSwitch integration bridge. This creates a row in the Interface table > +of the Open_vSwitch database. As explained in the [IntegrationGuide.md], > +the vif-id associated with the VM network interface gets added in the > +external_ids:iface-id column of the newly created row in the Interface table. > + > +* Since VM-A belongs to a logical network, it gets an IP address. This IP > +address is used to spawn containers (either manually or through container > +orchestration systems) inside that VM and to monitor the health of the > +created containers. > + > +* The vif-id associated with the VM's network interface can be obtained by > +making a call to Neutron using tenant credentials. > + > +* This flow assumes a component called a "container network plugin". > +If you take Docker as an example for containers, you could envision > +the plugin to be either a wrapper around Docker or a feature of Docker itself > +that understands how to perform part of this workflow to get a container > +connected to a logical network managed by Neutron. The rest of the flow > +refers to this logical component that does not yet exist as the > +"container network plugin". > + > +* All the calls to Neutron will need tenant credentials. These calls can > +either be made from inside the tenant VM as part of a container network > plugin > +or from outside the tenant VM (if the tenant is not comfortable using > temporary > +Keystone tokens from inside the tenant VMs). For simplicity, this document > +explains the work flow using the former method. > + > +* The container hosting VM will need Open vSwitch installed in it. The only > +work for Open vSwitch inside the VM is to tag network traffic coming from > +containers. > + > +* When a container needs to be created inside the VM with a container network > +interface that is expected to be attached to a particular logical switch, the > +network plugin in that VM chooses any unused VLAN (This VLAN tag only needs > to > +be unique inside that VM. This limits the number of container interfaces to > +4096 inside a single VM). This VLAN tag is stripped out in the hypervisor > +by OVN and is only useful as a context (or metadata) for OVN. > + > +* The container network plugin then makes a call to Neutron to create a > +logical port. In addition to all the inputs that a call to create a port in > +Neutron that are currently needed, it sends the vif-id and the VLAN tag as > +inputs. > + > +* Neutron in turn will verify that the vif-id belongs to the tenant in > question > +and then uses the OVN specific plugin to create a new row in the Logical_Port > +table of the OVN Northbound Database. Neutron re
Re: [ovs-dev] [PATCH] ovn: Design and Schema changes for Container integration.
> > It's expected that containers will be created and destroyed at a much > faster rate than typically experienced with just VMs. With that in > mind, seeing Neutron REST API calls in this flow may make people worry > about the increased setup time. It seems to me that logical ports could > optionally be reused to avoid this cost at the creation of every > container. Can you think of a reason that would be problematic? I don't see a reason for it to be problematic. I think it is a valid use case. > > If that sounds OK, how about this as some additional text here: > > * The Neutron API call here to create a logical port for the container > could add a relatively significant amount of time to container creation. > However, an optimization is possible here. Logical ports could be > created in advance and reused by the container system doing container > orchestration. Additional Neutron API calls would only be needed if the > port needs to be attached to a different logical I will add this as part of v2. Thank you for the text! > >> +* When a container is eventually deleted, the network plugin in that VM >> +will make a call to Neutron to delete that port. Neutron in turn will >> +delete the entry in the Logical_Port table of the OVN Northbound Database. > > If the above text is added, I would change "will make a call" to "may > make a call". > > -- > Russell Bryant ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn: Design and Schema changes for Container integration.
> > * The Neutron API call here to create a logical port for the container > could add a relatively significant amount of time to container creation. > However, an optimization is possible here. Logical ports could be > created in advance and reused by the container system doing container > orchestration. Additional Neutron API calls would only be needed if the > port needs to be attached to a different logical I spoke to a couple of guys from the Neutron project about how much is 'relatively significant amount of time'? The answer I get is that it takes less than a second to create a port. (On my relatively large internal openstack cloud, my experience with creation of a Neutron port has been fast too. Yes, there are times, when it looks like it takes time). In your experience, on an average, how many seconds does it take to create a Neutron port? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/2] bashcomp: Install and package completion scripts.
Thx a lot for the review and helpful comments, updated the ovs-command-bashcomp.INSTALL.md. Applied both patches to master, Let's make people use the completion functionality and make it better, Thanks, Alex Wang, On Thu, Mar 19, 2015 at 5:49 PM, Alex Wang wrote: > > > On Thu, Mar 19, 2015 at 5:08 PM, Peter Amidon > wrote: > >> On Wed, 18 Mar 2015 14:47:25 -0700: Alex Wang wrote: >> >> >> > This commit makes the bash completion scripts be installed to >> > /etc/bash_completion.d through 'make install' or package installation. >> > This will make the scripts available for each bash session. >> >> > An alternative is to put scripts to /usr/share/bash_completion/ >> directory. >> > However, this is not supported by earlier version of bash completion. >> >> > Signed-off-by: Alex Wang >> >> These changes look good to me overall, but I just realized that >> utilities/ovs-command-bashcomp.INSTALL.md still talks about how to >> manually install the scripts into /etc/bash_completion.d. Should we >> also change it to make it clear that the scripts will be installed by >> default, with an explanation of how to manually use them in other cases? >> >> > Yeah, thx for pointing it out! I'll do that, > > Are you okay with the patch 1/2? > > > > >> Thanks, >> >> Peter Amidon >> > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn: Design and Schema changes for Container integration.
- Original Message - > > > > * The Neutron API call here to create a logical port for the container > > could add a relatively significant amount of time to container creation. > > However, an optimization is possible here. Logical ports could be > > created in advance and reused by the container system doing container > > orchestration. Additional Neutron API calls would only be needed if the > > port needs to be attached to a different logical > I spoke to a couple of guys from the Neutron project about how much is > 'relatively significant amount of time'? > The answer I get is that it takes less than a second to create a port. > (On my relatively large internal openstack cloud, my experience with > creation of a Neutron port has been fast too. Yes, there are times, > when it looks like it takes time). > > In your experience, on an average, how many seconds does it take to > create a Neutron port? > I don't have a number to offer. It's more theoretical. In the best case it's "fast", of course. I'm assuming that something taking a few seconds has real meaning here in comparison to container creation and in some cases container runtime. The API call to create a port for a container has a lot of interactions between different systems that seem to me could reasonably add up to an amount of time considered meaningful for containers. Here's a more detailed view of those interactions. This is from memory, so don't hold me to the exact details. :-) 1) If the container manager has a Keystone token and a copy of the service catalog, great. If not, the container manager must issue a REST API call to the Keystone API to authenticate, get a token, and get a copy of the service catalog. It may then make multiple round trips to backend services, depending on configuration: 1a) Keystone will then hit a SQL server or LDAP service to process authentication. 1b) Keystone may hit a SQL server to load the service catalog. 1c) Keystone may hit a SQL server to store the token it generates after successful authentication. 2) Now the container manager can issue the port request to Neutron. This is a REST API call to the Neutron API service. This results in: 2a) Depending on the Keystone setup, the Neutron API service may have to do a REST API call over to Keystone to validate that the token is valid. 2b) Neutron will hit a SQL server to retrieve details about the network the port is associated with. 2c) Neutron will hit a SQL server to create a new record for the port being created. 2d) In the OVN driver, it's going to look at the parent port ID and do another SQL server query to make sure that port is valid and is accessible by this tenant. 2e) The OVN driver will create the port in the OVN northbound DB. 2f) At this point, the container manager needs to wait for the port to be marked as 'up'. There is a mechanism where Neutron will asynchronously issue a REST API call back to Nova (the VM management service) to let it know that a port is ready. In this container integration case, we'll have to come up with a way for that notification to go to the container manager, instead. So, we've got 1 REST API call with a few round-trips to a SQL database at best. At worst, it's 3 REST API calls with 6 SQL round trips. After all that there's some undefined synchronization method needed with the container manager to let it know the port is 'up'. I feel like I may be forgetting something, but that's the general idea. The optimization would let the container manager do that process *far* less often, which seems like a nice win. -- Russell Bryant ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v4 1/5] Sanitize remaining recirculation parameters.
I'm a little confused about the motivation for this change.
IIRC the idea of having recirculation fields in the xlate_ctx structure was
to avoid having to pass around extra function parameters, like the ones
this patch adds. I'm not necessarily opposed to that. But I think it is
worth adding some context to the discussion.
On Thu, Mar 19, 2015 at 06:03:25PM -0700, Jarno Rajahalme wrote:
> Signed-off-by: Jarno Rajahalme
> ---
> ofproto/ofproto-dpif-xlate.c | 66
> +-
> ofproto/ofproto-dpif-xlate.h |6
> 2 files changed, 39 insertions(+), 33 deletions(-)
>
> diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
> index 0e28c77..ece9670 100644
> --- a/ofproto/ofproto-dpif-xlate.c
> +++ b/ofproto/ofproto-dpif-xlate.c
> @@ -208,14 +208,13 @@ struct xlate_ctx {
> uint16_t user_cookie_offset;/* Used for user_action_cookie fixup. */
> bool exit; /* No further actions should be processed. */
>
> -bool use_recirc;/* Should generate recirc? */
> -struct xlate_recirc recirc; /* Information used for generating
> - * recirculation actions */
> -
> /* True if a packet was but is no longer MPLS (due to an MPLS pop
> action).
> * This is a trigger for recirculation in cases where translating an
> action
> * or looking up a flow requires access to the fields of the packet after
> - * the MPLS label stack that was originally present. */
> + * the MPLS label stack that was originally present.
> + *
> + * XXX: output to a table and patch port do not currently recirculate
> even
> + * if this is true. */
> bool was_mpls;
>
> /* OpenFlow 1.1+ action set.
> @@ -353,7 +352,16 @@ static bool input_vid_is_valid(uint16_t vid, struct
> xbundle *, bool warn);
> static uint16_t input_vid_to_vlan(const struct xbundle *, uint16_t vid);
> static void output_normal(struct xlate_ctx *, const struct xbundle *,
>uint16_t vlan);
> -static void compose_output_action(struct xlate_ctx *, ofp_port_t ofp_port);
> +
> +/* Optional bond recirculation parameter to compose_output_action(). */
> +struct xlate_bond_recirc {
> +uint32_t recirc_id; /* !0 Use recirculation instead of output. */
> +uint8_t hash_alg; /* !0 Compute hash for recirc before. */
> +uint32_t hash_basis; /* Compute hash for recirc before. */
> +};
> +
> +static void compose_output_action(struct xlate_ctx *, ofp_port_t ofp_port,
> + const struct xlate_bond_recirc *xr);
>
> static struct xbridge *xbridge_lookup(struct xlate_cfg *,
>const struct ofproto_dpif *);
> @@ -1670,28 +1678,28 @@ output_normal(struct xlate_ctx *ctx, const struct
> xbundle *out_xbundle,
> uint16_t vid;
> ovs_be16 tci, old_tci;
> struct xport *xport;
> +struct xlate_bond_recirc xr;
> +bool use_recirc = false;
>
> vid = output_vlan_to_vid(out_xbundle, vlan);
> if (list_is_empty(&out_xbundle->xports)) {
> /* Partially configured bundle with no slaves. Drop the packet. */
> return;
> } else if (!out_xbundle->bond) {
> -ctx->use_recirc = false;
> xport = CONTAINER_OF(list_front(&out_xbundle->xports), struct xport,
> bundle_node);
> } else {
> struct xlate_cfg *xcfg = ovsrcu_get(struct xlate_cfg *, &xcfgp);
> struct flow_wildcards *wc = &ctx->xout->wc;
> -struct xlate_recirc *xr = &ctx->recirc;
> struct ofport_dpif *ofport;
>
> if (ctx->xbridge->enable_recirc) {
> -ctx->use_recirc = bond_may_recirc(
> -out_xbundle->bond, &xr->recirc_id, &xr->hash_basis);
> +use_recirc = bond_may_recirc(
> +out_xbundle->bond, &xr.recirc_id, &xr.hash_basis);
>
> -if (ctx->use_recirc) {
> +if (use_recirc) {
> /* Only TCP mode uses recirculation. */
> -xr->hash_alg = OVS_HASH_ALG_L4;
> +xr.hash_alg = OVS_HASH_ALG_L4;
> bond_update_post_recirc_rules(out_xbundle->bond, false);
>
> /* Recirculation does not require unmasking hash fields. */
> @@ -1708,9 +1716,9 @@ output_normal(struct xlate_ctx *ctx, const struct
> xbundle *out_xbundle,
> return;
> }
>
> -/* If ctx->xout->use_recirc is set, the main thread will handle stats
> +/* If use_recirc is set, the main thread will handle stats
> * accounting for this bond. */
> -if (!ctx->use_recirc) {
> +if (!use_recirc) {
> if (ctx->xin->resubmit_stats) {
> bond_account(out_xbundle->bond, &ctx->xin->flow, vid,
> ctx->xin->resubmit_stats->n_bytes);
> @@ -1738,7 +1746,7 @@ output_normal(struct xlate_ctx *ctx, const struct
> xbundl
Re: [ovs-dev] [PATCH v4 1/5] Sanitize remaining recirculation parameters.
> On Mar 20, 2015, at 5:30 PM, Simon Horman wrote:
>
> I'm a little confused about the motivation for this change.
>
> IIRC the idea of having recirculation fields in the xlate_ctx structure was
> to avoid having to pass around extra function parameters, like the ones
> this patch adds. I'm not necessarily opposed to that. But I think it is
> worth adding some context to the discussion.
Ben proposed that part of this patch. I feel that there is a balance between
the “context” and function parameters. In this case the context would be very
short lived and only affect a direct and short function call path, and hence I
think function parameters make more sense.
Jarno
>
> On Thu, Mar 19, 2015 at 06:03:25PM -0700, Jarno Rajahalme wrote:
>> Signed-off-by: Jarno Rajahalme
>> ---
>> ofproto/ofproto-dpif-xlate.c | 66
>> +-
>> ofproto/ofproto-dpif-xlate.h |6
>> 2 files changed, 39 insertions(+), 33 deletions(-)
>>
>> diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
>> index 0e28c77..ece9670 100644
>> --- a/ofproto/ofproto-dpif-xlate.c
>> +++ b/ofproto/ofproto-dpif-xlate.c
>> @@ -208,14 +208,13 @@ struct xlate_ctx {
>> uint16_t user_cookie_offset;/* Used for user_action_cookie fixup. */
>> bool exit; /* No further actions should be processed. */
>>
>> -bool use_recirc;/* Should generate recirc? */
>> -struct xlate_recirc recirc; /* Information used for generating
>> - * recirculation actions */
>> -
>> /* True if a packet was but is no longer MPLS (due to an MPLS pop
>> action).
>> * This is a trigger for recirculation in cases where translating an
>> action
>> * or looking up a flow requires access to the fields of the packet after
>> - * the MPLS label stack that was originally present. */
>> + * the MPLS label stack that was originally present.
>> + *
>> + * XXX: output to a table and patch port do not currently recirculate
>> even
>> + * if this is true. */
>> bool was_mpls;
>>
>> /* OpenFlow 1.1+ action set.
>> @@ -353,7 +352,16 @@ static bool input_vid_is_valid(uint16_t vid, struct
>> xbundle *, bool warn);
>> static uint16_t input_vid_to_vlan(const struct xbundle *, uint16_t vid);
>> static void output_normal(struct xlate_ctx *, const struct xbundle *,
>> uint16_t vlan);
>> -static void compose_output_action(struct xlate_ctx *, ofp_port_t ofp_port);
>> +
>> +/* Optional bond recirculation parameter to compose_output_action(). */
>> +struct xlate_bond_recirc {
>> +uint32_t recirc_id; /* !0 Use recirculation instead of output. */
>> +uint8_t hash_alg; /* !0 Compute hash for recirc before. */
>> +uint32_t hash_basis; /* Compute hash for recirc before. */
>> +};
>> +
>> +static void compose_output_action(struct xlate_ctx *, ofp_port_t ofp_port,
>> + const struct xlate_bond_recirc *xr);
>>
>> static struct xbridge *xbridge_lookup(struct xlate_cfg *,
>> const struct ofproto_dpif *);
>> @@ -1670,28 +1678,28 @@ output_normal(struct xlate_ctx *ctx, const struct
>> xbundle *out_xbundle,
>> uint16_t vid;
>> ovs_be16 tci, old_tci;
>> struct xport *xport;
>> +struct xlate_bond_recirc xr;
>> +bool use_recirc = false;
>>
>> vid = output_vlan_to_vid(out_xbundle, vlan);
>> if (list_is_empty(&out_xbundle->xports)) {
>> /* Partially configured bundle with no slaves. Drop the packet. */
>> return;
>> } else if (!out_xbundle->bond) {
>> -ctx->use_recirc = false;
>> xport = CONTAINER_OF(list_front(&out_xbundle->xports), struct xport,
>> bundle_node);
>> } else {
>> struct xlate_cfg *xcfg = ovsrcu_get(struct xlate_cfg *, &xcfgp);
>> struct flow_wildcards *wc = &ctx->xout->wc;
>> -struct xlate_recirc *xr = &ctx->recirc;
>> struct ofport_dpif *ofport;
>>
>> if (ctx->xbridge->enable_recirc) {
>> -ctx->use_recirc = bond_may_recirc(
>> -out_xbundle->bond, &xr->recirc_id, &xr->hash_basis);
>> +use_recirc = bond_may_recirc(
>> +out_xbundle->bond, &xr.recirc_id, &xr.hash_basis);
>>
>> -if (ctx->use_recirc) {
>> +if (use_recirc) {
>> /* Only TCP mode uses recirculation. */
>> -xr->hash_alg = OVS_HASH_ALG_L4;
>> +xr.hash_alg = OVS_HASH_ALG_L4;
>> bond_update_post_recirc_rules(out_xbundle->bond, false);
>>
>> /* Recirculation does not require unmasking hash fields. */
>> @@ -1708,9 +1716,9 @@ output_normal(struct xlate_ctx *ctx, const struct
>> xbundle *out_xbundle,
>> return;
>> }
>>
>> -/* If ctx->xout->use_recirc is set, the main thread will handle
>> stats
>> +/* If use_recirc is
[ovs-dev] agriculture and feed
RISHON Agritech Co., Ltd(E-mail:i...@rsagritech.comris...@rsagritech.com) is professionally working on agriculture and feed industry, our products mainly include: >Fertilizer N-P-K Compound (N-P-K+TE,CA,MG,MN,CU,ZN...) Phosphate Chemicals -TG/FG (MAP,DAP,MKP,DKP...) Ammoinium Phosphate Potassium Phosphate Sodium Phosphate Growth Regulators (IBA, NAA, 5NG...) Granular/Powder Metal Chelates(EDTA-FE-13,DTPA-FE-11,EDTA-ZN-15,EDTA-MG-6...) Water Soluble Potassium Silicate >Feed Supplement Amino Acid Chelate (Molybdenum,Calcium,Iron,Copper..Amino Acid Chelate..) Amino Acids/Vitamins (Compound AA, VA,VE...) Feed Fatty Acids (ARA,DHA...) Arachidonic Acid Docosahexaenoic Acid Gamma Linolenic Acid Feed Phosphates (MCP,DCP,MDCP,TCP...) Calcium Phosphate Pls contact us freely for any requirement at below: - RISHON Agritech CO., Ltd - Address: 172#, North Tianshan Road, Deyang City, P.R.China - E-mail:i...@rsagritech.comris...@rsagritech.com - [Thanks Again for your Time] ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
