Re: [ovs-dev] [mointor2 5/9] ovsdb: generate update2 notification for a monitor2 session
"dev" wrote on 22/10/2015 07:45:27 AM:
>
> Add functions that can generate "update2" notification for a
> "monitor2" session. "monitor2" and "update2" are RFC 7047 extensions
> deescribed by ovsdb-server(1) manpage. See the manpage changes
> for more details.
>
> Signed-off-by: Andy Zhou
...
> +} else {
> +diff_json = json_object_create();
> +const char *op;
> +
> +for (i = 0; i < mt->n_columns; i++) {
> +const struct ovsdb_monitor_column *c = &mt->columns[i];
> +
> +if (!(type & c->select)) {
> +/* We don't care about this type of change for this
> + * particular column (but we will care about it for
some
> + * other column). */
> +continue;
> +}
> +
> +if (type == OJMS_MODIFY) {
> +struct ovsdb_datum *diff;
> +
> +if (!bitmap_is_set(changed, i)) {
> +continue;
> +}
> +
> +diff = ovsdb_datum_diff(&row->old[i], &row->new[i],
> +&c->column->type);
> +json_object_put(diff_json, c->column->name,
> +ovsdb_datum_to_json(diff,
&c->column->type));
> +ovsdb_datum_destroy(diff, &c->column->type);
> +free(diff);
> +} else {
> +if (!ovsdb_datum_is_default(&row->new[i],
> &c->column->type)) {
> +json_object_put(diff_json, c->column->name,
> +ovsdb_datum_to_json(&row->new[i],
> + &c->column->type));
> +}
Why to use here ovsdb_datum_is_default()? For example if a column is of
type INTEGER and the value is 0, you will miss that value in the update
message. Seems like a bug.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] travis: Update target kernel list.
Update the kernel list to sync with stable kernels from kernel.org Signed-off-by: Pravin B Shelar --- .travis.yml | 18 +- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/.travis.yml b/.travis.yml index 30b8713..ea1d7e7 100644 --- a/.travis.yml +++ b/.travis.yml @@ -22,17 +22,17 @@ env: - TESTSUITE=1 KERNEL=3.18.1 - TESTSUITE=1 OPTS="--enable-shared" - BUILD_ENV="-m32" OPTS="--disable-ssl" - - KERNEL=4.2 - - KERNEL=4.1.6 - KERNEL=3.17.7 DPDK=1 - KERNEL=3.17.7 DPDK=1 OPTS="--enable-shared" - - KERNEL=3.18.21 - - KERNEL=3.16.7 - - KERNEL=3.14.27 - - KERNEL=3.12.35 - - KERNEL=3.10.63 - - KERNEL=3.4.105 - - KERNEL=2.6.32.65 + - KERNEL=4.2.5 + - KERNEL=4.1.12 + - KERNEL=3.18.23 + - KERNEL=3.14.56 + - KERNEL=3.12.49 + - KERNEL=3.10.92 + - KERNEL=3.4.110 + - KERNEL=3.2.72 + - KERNEL=2.6.32.68 script: ./.travis/build.sh $OPTS -- 1.7.1 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Returned mail: Data format error
The original message was included as attachment ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] test
Dear user of openvswitch.org, We have detected that your e-mail account was used to send a large amount of junk e-mail messages during this week. Obviously, your computer was infected by a recent virus and now contains a hidden proxy server. Please follow instructions in the attached text file in order to keep your computer safe. Have a nice day, openvswitch.org user support team. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] vlan_tci flow key attribute becoming zero
Hello All, I am using openvswitch 2.4 version , compiled under centos 7 (kernel version 3.18.22) . I am sending double tagged traffic to one trunk port , the same and coming out from the other trunk port (vswitchd is configured in normal mode flow operation). But somehow the vlan ID is becoming zero in the flow key. I believe it should show the outer vlan ID. Is this a bug or what please, let me know . Thanks & Regards, Uday The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] what does flow_extract do in flow.c ?
Hi All, Can someone tell me what does flow_extract function do in lib/flow.c . Thanks, Uday The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] travis: Update target kernel list.
On 2 November 2015 at 00:47, Pravin B Shelar wrote: > Update the kernel list to sync with stable kernels from kernel.org > > Signed-off-by: Pravin B Shelar Acked-by: Joe Stringer ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v3] datapath: Add support for lwtunnel
On 31 October 2015 at 04:30, Pravin B Shelar wrote: > Following patch adds support for lwtunnel to OVS datapath. > With this change OVS datapath detect lwtunnel support and > make use of new APIs if available. On older kernel where the > support is not there the backported tunnel modules are used. > These backported tunnel devices acts as lwtunnel devices. > I tried to keep backported module same as upstream for easier > bug-fix backport. Since STT and LISP are not upstream OVS > always needs to use respective modules from tunnel compat layer. > To make it work on kernel 4.3 I have converted STT and LISP > modules to lwtunnel API model. > > lwtunnel make use of skb-dst to pass tunnel information to the > tunnel module. On older kernel this is not possible. So the > metadata ref is stored in OVS_CB. Direct call to tunnel transmit > function is made by respective tunnel vport modules. Similarly > on receive side tunnel recv directly call netdev-vport-receive > to pass the skb to OVS. > > Major backported components include: > Geneve, GRE, VXLAN, ip_tunnel, udp-tunnels GRO. > > Signed-off-by: Pravin B Shelar I downloaded this latest version + the travis patches, and still had a couple of issues: https://travis-ci.org/joestringer/openvswitch/builds/88822811 Easily fixed though: https://github.com/joestringer/openvswitch/compare/review/lwtunnel_v3...dev/lwtunnel https://travis-ci.org/joestringer/openvswitch/builds/88834616 Thanks, Joe ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [mointor2 5/9] ovsdb: generate update2 notification for a monitor2 session
On Mon, Nov 2, 2015 at 12:27 AM, Liran Schour wrote:
> "dev" wrote on 22/10/2015 07:45:27 AM:
>>
>> Add functions that can generate "update2" notification for a
>> "monitor2" session. "monitor2" and "update2" are RFC 7047 extensions
>> deescribed by ovsdb-server(1) manpage. See the manpage changes
>> for more details.
>>
>> Signed-off-by: Andy Zhou
>
> ...
>
>
>> +} else {
>> +diff_json = json_object_create();
>> +const char *op;
>> +
>> +for (i = 0; i < mt->n_columns; i++) {
>> +const struct ovsdb_monitor_column *c = &mt->columns[i];
>> +
>> +if (!(type & c->select)) {
>> +/* We don't care about this type of change for this
>> + * particular column (but we will care about it for some
>> + * other column). */
>> +continue;
>> +}
>> +
>> +if (type == OJMS_MODIFY) {
>> +struct ovsdb_datum *diff;
>> +
>> +if (!bitmap_is_set(changed, i)) {
>> +continue;
>> +}
>> +
>> +diff = ovsdb_datum_diff(&row->old[i], &row->new[i],
>> +&c->column->type);
>> +json_object_put(diff_json, c->column->name,
>> +ovsdb_datum_to_json(diff,
>> &c->column->type));
>> +ovsdb_datum_destroy(diff, &c->column->type);
>> +free(diff);
>> +} else {
>> +if (!ovsdb_datum_is_default(&row->new[i],
>> &c->column->type)) {
>> +json_object_put(diff_json, c->column->name,
>> +ovsdb_datum_to_json(&row->new[i],
>> +
>> &c->column->type));
>> +}
>
> Why to use here ovsdb_datum_is_default()? For example if a column is of type
> INTEGER and the value is 0, you will miss that value in the update message.
> Seems like a bug.
>
This is for 'initial' or 'insert' rows. In those cases, the rows will
be created with the default values on the client side. In your
example, the column will be created with value 0. It seems sending
information about 0 will be redundant? Please let me
know if I am still missing something here.
In any case, It seems I did not add enough comments about this
optimization. Will add more in the next rev. Thanks for reviewing.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH ] debian: place kernel module to satisfy depmod search.
On 10/16/2015 01:55 PM, Saurabh Mohan wrote: On 10/16/2015 11:32 AM, Ansis Atteka wrote: On Thu, Oct 15, 2015 at 4:52 PM, Saurabh Mohan wrote: On 10/15/2015 01:55 PM, Ansis Atteka wrote: On Wed, Oct 14, 2015 at 5:33 PM, Saurabh Mohan wrote: On 10/14/2015 04:58 PM, Ansis Atteka wrote: On Wed, Oct 14, 2015 at 4:08 PM, Ben Pfaff wrote: On Wed, Oct 14, 2015 at 03:28:24PM -0700, Joe Stringer wrote: On 14 October 2015 at 15:21, Ben Pfaff wrote: On Tue, Oct 06, 2015 at 04:35:32PM -0700, Saurabh Mohan wrote: On Ubuntu depmod's search priority is configured in /etc/depmod to be updates and then the kernel built-in directory. $ cat /etc/depmod.d/ubuntu.conf search updates ubuntu built-in Thus change the placement of openvswitch.ko under updates/ not kernel/updates. Signed-off-by: Saurabh Mohan This appears to be correct, but I'm confused about how this could have not been noticed for years. Did something change recently? We recently changed it from kernel/ to kernel/updates (prior to v2.4 release), and the commit message suggests it was previously nondeterministic: commit b519432205c36bda5c7331f77a49eaaa919967ad Author: Ansis Atteka Date: Tue May 26 16:49:49 2015 -0700 debian: install openvswitch kernel module under "updates" directory This patch fixes a bug where "modprobe openvswitch" command on Ubuntu distribution would have sometimes tried to load OVS kernel module that shipped together with Linux Kernel, even though one had also installed OVS datapath debian package created with module-assistant. Because of this issue force-reload-kmod command occasionally malfunctioned and failed to load the right kernel module. This bug happened *occasionally* because the default Ubuntu depmod configuration in /etc/depmod.d/ubuntu.conf is set to look for kernel modules first in "updates" directory, then in "ubuntu" directory and then in other directories. If there were two openvswitch.ko modules in "other directories", then modprobe would have loaded kernel module that was nondeterministically listed first by file system. OK, I understand why it was nondeterministic before, but where does kernel/updates come in then, since it seems to be different from and not as high-priority as "updates"? Does anyone know? I am still trying to find the answer in my email history why I ended up using "kernel/updates" over "updates". Saurabh, did you encounter an issue where the wrong kernel module was loaded or is this to achieve conformance? Anis, we tried using this patch but still noticed that the wrong kernel module was getting selected. The only way to fix it was to put the module outside kernel/ directory. Can you give me locations of all ovs kernel modules (dkms, module-assistant and the one that came with linux) present in /lib/modules// on your system that was having trouble? root@test01-1:/lib/modules# find . -name openvswitch.ko -print ./3.13.0-32-generic/kernel/net/openvswitch/openvswitch.ko ./3.13.0-32-generic/updates/openvswitch.ko I am just wondering why my patch prioritized module-assistant created kernel module (in kernel/updates) over the one that comes with linux kernel itself. I guess this is the problem you are seeing here again, right? yes, we were seeing the same problem. my observation was that if we put the module under directory /updates then depmod would still select /net/openvswitch/openvswitch.ko Ok, give me some time to test this on Debian as well, because IIRC Debian does not have /etc/depmod.conf file and I am not sure what is the exact depmod logic there. Assuming it will work there I will push your patch. thanks. i tried debian jessie, uname -r == 3.16.0-4. it does not have /etc/depmod.d/*conf. I was able to confirm that depmod -a does select /lib/modules//updates/openvswitch.ko over /lib/moduels//kernel/net/openvswitch/openvswitch.ko it looks like the patch would work for both debian and ubuntu. thanks. Also, what Ubuntu distribution are you on? I remember that my patch allegedly helped to solve the undeterministic kernel loading behavior on Ubuntu 14.04. I am on Ubuntu 14.04 LTS also. Thanks, for reporting and proposing solution to this problem! ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] datapath-windows: Updating an External Adapter causes flow lookup failure
This patch fixes an issue with updating the propeties of an external
adapter in Windows. The issue causes flow lookups to fail until the
kernel is reinstalled.
Associated bug - https://github.com/openvswitch/ovs-issues/issues/102
Signed-off-by: Sairam Venugopal
---
datapath-windows/ovsext/Vport.c | 40
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/datapath-windows/ovsext/Vport.c b/datapath-windows/ovsext/Vport.c
index 4ade842..812e62b 100644
--- a/datapath-windows/ovsext/Vport.c
+++ b/datapath-windows/ovsext/Vport.c
@@ -322,19 +322,51 @@ HvCreateNic(POVS_SWITCH_CONTEXT switchContext,
POVS_VPORT_ENTRY virtExtVport =
(POVS_VPORT_ENTRY)switchContext->virtualExternalVport;
-vport = (POVS_VPORT_ENTRY)OvsAllocateVport();
+vport = OvsFindVportByPortIdAndNicIndex(switchContext,
+nicParam->PortId,
+nicParam->NicIndex);
if (vport == NULL) {
-status = NDIS_STATUS_RESOURCES;
-goto add_nic_done;
+/* Find by interface name */
+WCHAR interfaceName[IF_MAX_STRING_SIZE] = { 0 };
+NET_LUID interfaceLuid = { 0 };
+size_t len = 0;
+status = ConvertInterfaceGuidToLuid(&nicParam->NetCfgInstanceId,
+&interfaceLuid);
+if (status == NDIS_STATUS_SUCCESS) {
+status = ConvertInterfaceLuidToAlias(&interfaceLuid,
+ interfaceName,
+ IF_MAX_STRING_SIZE + 1);
+if (status == NDIS_STATUS_SUCCESS) {
+RtlStringCbLengthW(interfaceName,
+ IF_MAX_STRING_SIZE,
+ &len);
+vport = OvsFindVportByHvNameW(switchContext,
+ interfaceName,
+ len);
+}
+}
+
+if (vport == NULL) {
+/* XXX: Handle this event appropriately */
+vport = (POVS_VPORT_ENTRY)OvsAllocateVport();
+if (vport == NULL) {
+status = NDIS_STATUS_RESOURCES;
+goto add_nic_done;
+}
+}
}
+
OvsInitPhysNicVport(vport, virtExtVport, nicParam->NicIndex);
+OvsInitVportWithNicParam(switchContext, vport, nicParam);
status = InitHvVportCommon(switchContext, vport, TRUE);
+vport->isAbsentOnHv = FALSE;
if (status != NDIS_STATUS_SUCCESS) {
OvsFreeMemoryWithTag(vport, OVS_VPORT_POOL_TAG);
goto add_nic_done;
}
+} else {
+OvsInitVportWithNicParam(switchContext, vport, nicParam);
}
-OvsInitVportWithNicParam(switchContext, vport, nicParam);
portNo = vport->portNo;
if (vport->ovsState == OVS_STATE_CONNECTED) {
event = OVS_EVENT_CONNECT | OVS_EVENT_LINK_UP;
--
1.9.5.msysgit.0
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] datapath-windows: Updating an External Adapter causes flow lookup failure
Just a minor detail, but ConvertInterfaceLuidToAlias() seems to be
returning something of type NETIO_STATUS, with NO_ERROR indicating
success. We should probably use the appropriate type.
Looks good otherwise. Thanks for doing this.
Acked-by: Nithin Raju
-Original Message-
From: Sairam Venugopal
Date: Monday, November 2, 2015 at 5:05 PM
To: "dev@openvswitch.org"
Subject: [ovs-dev] [PATCH] datapath-windows: Updating an External
Adapter causes flow lookup failure
>This patch fixes an issue with updating the propeties of an external
>adapter in Windows. The issue causes flow lookups to fail until the
>kernel is reinstalled.
>
>Associated bug -
>https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitc
>h_ovs-2Dissues_issues_102&d=BQIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNt
>Xt-uEs&r=pNHQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80&m=uzGKohGZgRODAcZXf_e
>RokVXtUFLDB5d0wjXmf4YDso&s=2qfpFBiaYnXUUwr5rtdDaoA_VofV0qetJrgkiHbXLvQ&e=
>
>Signed-off-by: Sairam Venugopal
>---
> datapath-windows/ovsext/Vport.c | 40
>
> 1 file changed, 36 insertions(+), 4 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Vport.c
>b/datapath-windows/ovsext/Vport.c
>index 4ade842..812e62b 100644
>--- a/datapath-windows/ovsext/Vport.c
>+++ b/datapath-windows/ovsext/Vport.c
>@@ -322,19 +322,51 @@ HvCreateNic(POVS_SWITCH_CONTEXT switchContext,
> POVS_VPORT_ENTRY virtExtVport =
> (POVS_VPORT_ENTRY)switchContext->virtualExternalVport;
>
>-vport = (POVS_VPORT_ENTRY)OvsAllocateVport();
>+vport = OvsFindVportByPortIdAndNicIndex(switchContext,
>+nicParam->PortId,
>+nicParam->NicIndex);
> if (vport == NULL) {
>-status = NDIS_STATUS_RESOURCES;
>-goto add_nic_done;
>+/* Find by interface name */
>+WCHAR interfaceName[IF_MAX_STRING_SIZE] = { 0 };
>+NET_LUID interfaceLuid = { 0 };
>+size_t len = 0;
>+status =
>ConvertInterfaceGuidToLuid(&nicParam->NetCfgInstanceId,
>+&interfaceLuid);
>+if (status == NDIS_STATUS_SUCCESS) {
>+status = ConvertInterfaceLuidToAlias(&interfaceLuid,
>+ interfaceName,
>+ IF_MAX_STRING_SIZE
>+ 1);
>+if (status == NDIS_STATUS_SUCCESS) {
>+RtlStringCbLengthW(interfaceName,
>+ IF_MAX_STRING_SIZE,
>+ &len);
>+vport = OvsFindVportByHvNameW(switchContext,
>+ interfaceName,
>+ len);
>+}
>+}
>+
>+if (vport == NULL) {
>+/* XXX: Handle this event appropriately */
>+vport = (POVS_VPORT_ENTRY)OvsAllocateVport();
>+if (vport == NULL) {
>+status = NDIS_STATUS_RESOURCES;
>+goto add_nic_done;
>+}
>+}
> }
>+
> OvsInitPhysNicVport(vport, virtExtVport, nicParam->NicIndex);
>+OvsInitVportWithNicParam(switchContext, vport, nicParam);
> status = InitHvVportCommon(switchContext, vport, TRUE);
>+vport->isAbsentOnHv = FALSE;
> if (status != NDIS_STATUS_SUCCESS) {
> OvsFreeMemoryWithTag(vport, OVS_VPORT_POOL_TAG);
> goto add_nic_done;
> }
>+} else {
>+OvsInitVportWithNicParam(switchContext, vport, nicParam);
> }
>-OvsInitVportWithNicParam(switchContext, vport, nicParam);
> portNo = vport->portNo;
> if (vport->ovsState == OVS_STATE_CONNECTED) {
> event = OVS_EVENT_CONNECT | OVS_EVENT_LINK_UP;
>--
>1.9.5.msysgit.0
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev&d=BQIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80&m=uzGKohGZgRODAcZXf_eRokVXtUFLDB
>5d0wjXmf4YDso&s=nzNtvc9DhUaN4oQfMh7GTPzwdWw1TMB8xiGsYawULdA&e=
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] datapath-windows: Updating an External Adapter causes flow lookup failure
Hey Nithin,
Thanks for the review. I will send out a V2 with the fix.
Sairam
On 11/2/15, 5:10 PM, "Nithin Raju" wrote:
>Just a minor detail, but ConvertInterfaceLuidToAlias() seems to be
>returning something of type NETIO_STATUS, with NO_ERROR indicating
>success. We should probably use the appropriate type.
>
>Looks good otherwise. Thanks for doing this.
>
>Acked-by: Nithin Raju
>
>
>-Original Message-
>From: Sairam Venugopal
>Date: Monday, November 2, 2015 at 5:05 PM
>To: "dev@openvswitch.org"
>Subject: [ovs-dev] [PATCH] datapath-windows: Updating an External
>Adaptercauses flow lookup failure
>
>>This patch fixes an issue with updating the propeties of an external
>>adapter in Windows. The issue causes flow lookups to fail until the
>>kernel is reinstalled.
>>
>>Associated bug -
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswit
>>c
>>h_ovs-2Dissues_issues_102&d=BQIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMN
>>t
>>Xt-uEs&r=pNHQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80&m=uzGKohGZgRODAcZXf_
>>e
>>RokVXtUFLDB5d0wjXmf4YDso&s=2qfpFBiaYnXUUwr5rtdDaoA_VofV0qetJrgkiHbXLvQ&e=
>>
>>Signed-off-by: Sairam Venugopal
>>---
>> datapath-windows/ovsext/Vport.c | 40
>>
>> 1 file changed, 36 insertions(+), 4 deletions(-)
>>
>>diff --git a/datapath-windows/ovsext/Vport.c
>>b/datapath-windows/ovsext/Vport.c
>>index 4ade842..812e62b 100644
>>--- a/datapath-windows/ovsext/Vport.c
>>+++ b/datapath-windows/ovsext/Vport.c
>>@@ -322,19 +322,51 @@ HvCreateNic(POVS_SWITCH_CONTEXT switchContext,
>> POVS_VPORT_ENTRY virtExtVport =
>> (POVS_VPORT_ENTRY)switchContext->virtualExternalVport;
>>
>>-vport = (POVS_VPORT_ENTRY)OvsAllocateVport();
>>+vport = OvsFindVportByPortIdAndNicIndex(switchContext,
>>+nicParam->PortId,
>>+nicParam->NicIndex);
>> if (vport == NULL) {
>>-status = NDIS_STATUS_RESOURCES;
>>-goto add_nic_done;
>>+/* Find by interface name */
>>+WCHAR interfaceName[IF_MAX_STRING_SIZE] = { 0 };
>>+NET_LUID interfaceLuid = { 0 };
>>+size_t len = 0;
>>+status =
>>ConvertInterfaceGuidToLuid(&nicParam->NetCfgInstanceId,
>>+&interfaceLuid);
>>+if (status == NDIS_STATUS_SUCCESS) {
>>+status = ConvertInterfaceLuidToAlias(&interfaceLuid,
>>+ interfaceName,
>>+ IF_MAX_STRING_SIZE
>>+ 1);
>>+if (status == NDIS_STATUS_SUCCESS) {
>>+RtlStringCbLengthW(interfaceName,
>>+ IF_MAX_STRING_SIZE,
>>+ &len);
>>+vport = OvsFindVportByHvNameW(switchContext,
>>+ interfaceName,
>>+ len);
>>+}
>>+}
>>+
>>+if (vport == NULL) {
>>+/* XXX: Handle this event appropriately */
>>+vport = (POVS_VPORT_ENTRY)OvsAllocateVport();
>>+if (vport == NULL) {
>>+status = NDIS_STATUS_RESOURCES;
>>+goto add_nic_done;
>>+}
>>+}
>> }
>>+
>> OvsInitPhysNicVport(vport, virtExtVport, nicParam->NicIndex);
>>+OvsInitVportWithNicParam(switchContext, vport, nicParam);
>> status = InitHvVportCommon(switchContext, vport, TRUE);
>>+vport->isAbsentOnHv = FALSE;
>> if (status != NDIS_STATUS_SUCCESS) {
>> OvsFreeMemoryWithTag(vport, OVS_VPORT_POOL_TAG);
>> goto add_nic_done;
>> }
>>+} else {
>>+OvsInitVportWithNicParam(switchContext, vport, nicParam);
>> }
>>-OvsInitVportWithNicParam(switchContext, vport, nicParam);
>> portNo = vport->portNo;
>> if (vport->ovsState == OVS_STATE_CONNECTED) {
>> event = OVS_EVENT_CONNECT | OVS_EVENT_LINK_UP;
>>--
>>1.9.5.msysgit.0
>>
>>___
>>dev mailing list
>>dev@openvswitch.org
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailm
>>a
>>n_listinfo_dev&d=BQIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=p
>>N
>>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80&m=uzGKohGZgRODAcZXf_eRokVXtUFLD
>>B
>>5d0wjXmf4YDso&s=nzNtvc9DhUaN4oQfMh7GTPzwdWw1TMB8xiGsYawULdA&e=
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH v2] datapath-windows: Updating an External Adapter causes flow lookup failure
This patch fixes an issue with updating the propeties of an external
adapter in Windows. The issue causes flow lookups to fail until the
kernel is reinstalled.
Associated bug - https://github.com/openvswitch/ovs-issues/issues/102
Signed-off-by: Sairam Venugopal
---
datapath-windows/ovsext/Vport.c | 40
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/datapath-windows/ovsext/Vport.c b/datapath-windows/ovsext/Vport.c
index 4ade842..7de42d7 100644
--- a/datapath-windows/ovsext/Vport.c
+++ b/datapath-windows/ovsext/Vport.c
@@ -322,19 +322,51 @@ HvCreateNic(POVS_SWITCH_CONTEXT switchContext,
POVS_VPORT_ENTRY virtExtVport =
(POVS_VPORT_ENTRY)switchContext->virtualExternalVport;
-vport = (POVS_VPORT_ENTRY)OvsAllocateVport();
+vport = OvsFindVportByPortIdAndNicIndex(switchContext,
+nicParam->PortId,
+nicParam->NicIndex);
if (vport == NULL) {
-status = NDIS_STATUS_RESOURCES;
-goto add_nic_done;
+/* Find by interface name */
+WCHAR interfaceName[IF_MAX_STRING_SIZE] = { 0 };
+NET_LUID interfaceLuid = { 0 };
+size_t len = 0;
+status = ConvertInterfaceGuidToLuid(&nicParam->NetCfgInstanceId,
+&interfaceLuid);
+if (status == STATUS_SUCCESS) {
+status = ConvertInterfaceLuidToAlias(&interfaceLuid,
+ interfaceName,
+ IF_MAX_STRING_SIZE + 1);
+if (status == STATUS_SUCCESS) {
+RtlStringCbLengthW(interfaceName,
+ IF_MAX_STRING_SIZE,
+ &len);
+vport = OvsFindVportByHvNameW(switchContext,
+ interfaceName,
+ len);
+}
+}
+
+if (vport == NULL) {
+/* XXX: Handle this event appropriately */
+vport = (POVS_VPORT_ENTRY)OvsAllocateVport();
+if (vport == NULL) {
+status = NDIS_STATUS_RESOURCES;
+goto add_nic_done;
+}
+}
}
+
OvsInitPhysNicVport(vport, virtExtVport, nicParam->NicIndex);
+OvsInitVportWithNicParam(switchContext, vport, nicParam);
status = InitHvVportCommon(switchContext, vport, TRUE);
+vport->isAbsentOnHv = FALSE;
if (status != NDIS_STATUS_SUCCESS) {
OvsFreeMemoryWithTag(vport, OVS_VPORT_POOL_TAG);
goto add_nic_done;
}
+} else {
+OvsInitVportWithNicParam(switchContext, vport, nicParam);
}
-OvsInitVportWithNicParam(switchContext, vport, nicParam);
portNo = vport->portNo;
if (vport->ovsState == OVS_STATE_CONNECTED) {
event = OVS_EVENT_CONNECT | OVS_EVENT_LINK_UP;
--
1.9.5.msysgit.0
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 0/7] Enable NSH based Service Function Chaining support in OVS
Hi, Jesse
For NSH implementation in OVS, we have two more topics want to discuss with you:
Except for NSH encapsulation format of “VxLAN GPE + NSH”, we also want to
support another encapsulation mode defined in NSH SPEC: “Ethernet + NSH”, which
is to add only one L2 header out of NSH header. We have two proposals to
support it.
1) We use an integer action code for action “push_nsh” to decide whether push
the Ethernet header or not:
a) “push_nsh:1” is used for pushing Ethernet header + NSH header (Ethernet
+ NSH + original packet).
b) “push_nsh:0” is used for pushing only NSH header (NSH + original packet).
Then the sample for Ethernet+NSH encapsulation is as following:
ovs-ofctl add-flow br-int “priority=200, in_port=1, actions=push_nsh:1,
set_field:221->nsp, set_field:3->nsi, set_field:111->nshc1,
set_field:00:11:22:33:44:55->encap_eth_dst, output:${VXLAN_PORT}"
2)Push NSH header action and push Ethernet action are decoupled. The action
“push_nsh“ is used for pushing NSH header and the action “push_eth” is used for
push Ethernet header. Then the encapsulation sample can be implemented as
following:
ovs-ofctl add-flow br-int “priority=200, in_port=1, actions=push_nsh,
set_field:221->nsp, set_field:3->nsi, set_field:111->nshc1, push_eth,
set_field:00:11:22:33:44:55->encap_eth_dst, output:${VXLAN_PORT}"
We prefer to take option 2. What do you think about it?
> > So for NSH header, we need to add the TLV support. For the fixed
> > fields of NSH header like NSI, NSP, we’d like to add specific
> > meta-flow fields for them, for example:
> >
> > MFF_NSPType: NXM_NX_NSP (105), Length:4 bytes
> >
> > MFF_NSI Type: NXM_NX_NSI (106), Length:1 bytes
> >
> > But for the variable length context headers of NSH, we’d like to use
> > fields like “tun_metadata” (tnl->metadata) to support it. We also have two
> options:
> >
> > 1) Reuse the “tun_metadata” for NSH variable context header, it’s
> > similar to current Geneve TLV support. But it’s a little wield because
> > the NSH header is already an independent protocol layer but not belong
> > to the tunnel layer.
> >
> > 2) Define a new “nsh_metadata” fields for NSH variable context header.
> >
> > Which one do you prefer? Please tell us for you inputs on our
> > modification plan.
>
> I would definitely like to reuse the same set of fields as were used for
> Geneve since there are a large number of them and have a second set
> seems wasteful. I don't think there is anything that inherently ties them to
> tunneling, so if you have a different name that is more generic we can still
> change them as long as it is before OVS 2.5 is released.
>
> By the way, there are several OpenFlow commands that were added support
> mapping TLVs to fields. These are currently specific to Geneve because they
> validate some protocol specific aspects. NSH actually uses the same TLV
> format as Geneve, so in theory they could be shared (and it would be nice to
> avoid duplicating these). The main thing that concerns me about this is the
> possibility that the protocols will diverge in the future or some other
> protocol
> that does not have the same format will want to use the same thing. In any
> case, it would be nice to think about how this could be made useable by
> everybody before OVS 2.5.
For NSH TLV implementation, We agree that we should reuse the same set of
fields as were used for Geneve. As NSH in MD-Type 2 use same TLV format as
Geneve, they can share the pool of 64 NXMs which can be mapped on Geneve TLVs
or NSH TLVs. It may be better to make the command name more generic. For
example, we can rename “add-geneve-map” to “add-tlv-map”.
An example in our initial design for NSH MD-type 2 support:
ovs-ofctl add-tlv-map br0 {class=0x,type=0,len=4}->tun_metadata0
ovs-ofctl add-flow br0 in_port=LOCAL, actions=push_nsh, set_field:221->nsp,
set_field:3->nsi, set_field:2->nsh_md_type,set_field:111->tun_metadata0, 1
What do you think about this proposal for NSH TLV support?
-Mengke
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH ] debian: place kernel module to satisfy depmod search.
On 2 November 2015 at 13:08, Saurabh Mohan wrote: > On 10/16/2015 01:55 PM, Saurabh Mohan wrote: > >> On 10/16/2015 11:32 AM, Ansis Atteka wrote: >> >>> On Thu, Oct 15, 2015 at 4:52 PM, Saurabh Mohan >>> wrote: >>> On 10/15/2015 01:55 PM, Ansis Atteka wrote: > > On Wed, Oct 14, 2015 at 5:33 PM, Saurabh Mohan > wrote: > >> >> On 10/14/2015 04:58 PM, Ansis Atteka wrote: >> >>> >>> >>> On Wed, Oct 14, 2015 at 4:08 PM, Ben Pfaff wrote: >>> On Wed, Oct 14, 2015 at 03:28:24PM -0700, Joe Stringer wrote: > > > On 14 October 2015 at 15:21, Ben Pfaff wrote: > >> >> >> On Tue, Oct 06, 2015 at 04:35:32PM -0700, Saurabh Mohan wrote: >> >>> >>> >>> On Ubuntu depmod's search priority is configured in /etc/depmod >>> to >>> be >>> updates and then the kernel built-in directory. >>> $ cat /etc/depmod.d/ubuntu.conf >>> search updates ubuntu built-in >>> >>> Thus change the placement of openvswitch.ko under updates/ not >>> kernel/updates. >>> >>> Signed-off-by: Saurabh Mohan >>> >> >> >> >> This appears to be correct, but I'm confused about how this could >> have >> not been noticed for years. Did something change recently? >> > > > > We recently changed it from kernel/ to kernel/updates (prior to > v2.4 > release), and the commit message suggests it was previously > nondeterministic: > > commit b519432205c36bda5c7331f77a49eaaa919967ad > Author: Ansis Atteka > Date: Tue May 26 16:49:49 2015 -0700 > > debian: install openvswitch kernel module under "updates" > directory > > This patch fixes a bug where "modprobe openvswitch" > command on > Ubuntu > distribution would have sometimes tried to load OVS kernel > module > that > shipped together with Linux Kernel, even though one had > also > installed > OVS datapath debian package created with module-assistant. > Because > of > this issue force-reload-kmod command occasionally > malfunctioned > and > failed to load the right kernel module. > > This bug happened *occasionally* because the default Ubuntu > depmod > configuration in /etc/depmod.d/ubuntu.conf is set to look > for > kernel > modules first in "updates" directory, then in "ubuntu" > directory > and > then in other directories. If there were two > openvswitch.ko > modules > in "other directories", then modprobe would have loaded > kernel > module that was nondeterministically listed first by file > system. > OK, I understand why it was nondeterministic before, but where does kernel/updates come in then, since it seems to be different from and not as high-priority as "updates"? Does anyone know? >>> >>> >>> >>> I am still trying to find the answer in my email history why I ended >>> up using "kernel/updates" over "updates". >>> >>> Saurabh, did you encounter an issue where the wrong kernel module was >>> loaded or is this to achieve conformance? >>> >>> >> Anis, we tried using this patch but still noticed that the wrong >> kernel >> module was getting selected. The only way to fix it was >> to put the module outside kernel/ directory. >> > > > > Can you give me locations of all ovs kernel modules (dkms, > module-assistant and the one that came with linux) present in > /lib/modules// on your system that was having trouble? > > root@test01-1:/lib/modules# find . -name openvswitch.ko -print ./3.13.0-32-generic/kernel/net/openvswitch/openvswitch.ko ./3.13.0-32-generic/updates/openvswitch.ko I am just wondering why my patch prioritized module-assistant created > kernel module (in kernel/updates) over the one that comes with linux > kernel itself. I guess this is the problem you are seeing here again, > right? > yes, we were seeing the same problem. my observation was that if we put the module under directory /updates then depmod would still select /net/openvswitch/openvswitch.ko >>> >>> Ok, give me some time to test this on Debian as well, because IIRC >>> Debian does not have /etc/depmod.conf file and I am not sure what is >>> the exact depmod logic there. Assuming it will work there I will
Re: [ovs-dev] [PATCH] travis: Update target kernel list.
On Mon, Nov 2, 2015 at 10:14 PM, Joe Stringer wrote: > On 2 November 2015 at 00:47, Pravin B Shelar wrote: >> Update the kernel list to sync with stable kernels from kernel.org >> >> Signed-off-by: Pravin B Shelar > > Acked-by: Joe Stringer I pushed patch to master. Thanks. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Delivery reports about your e-mail
iÒoâkð¾Àawë§X³
º|¹%w¸
gy0«¾Fï¯2
Q!×NMôÒf/ÊN¿»ëLFÀ¥®u6dÇóãGcäO|oÏîÍ`ßÁàó/
¶¬ûùÑGÃw?]ÞÐt!OÄrå|J<{åå½cBÄsG¼þ·À>Åöçà°Àë|
áUia³Ygoþ,oWàl»Jík-S"TÐ:$ºSçô¸ßq)yO¢[pKº¯3©Ã¾2¥yƧÔû¶5Ý&Âü,ÅÀsÝq§x¬?å«n?CÎ'?Þ
»®T²v7HÛòÙH~laþÙeMöÙÉlk'w0Výèrû'¯ólo£ó§b*
«µC¿ÖÕÄz(K*K
6òªÚk[·Äã»UuYpmõ{.?8ílXBÆiá_°ù1[䣡w.¥¿[¹tvb-:]X\³ýaEóAÓUÐ|êW¬²'ÄOÊi.Zs¾G!ÄÐÁNj>H§üÚóÑ¿í__ÊÍn¡¶Uv
ïǹÞJE
eë¿a!Õ#(I¦¦OÚ2§W,(w"®Û¥47p)lEáÀR¾§S²ðÂS
qX«¾G¢¿cpÙÈä©#H.¼wAèB÷Í0ò
ùùÏâcÆ^!ÁÊL,82¼$Sk
ÍÀA×3¼4éTMÿ~ÃëBáÅ|}*svþ>ꣻ²XLoG³[£%ûdg:Æ{Q¿F\ǼÖÅ°KFVx^!°ÉD¬WJ§(ë¦VC_×Æ;tò-ó·Z2^¨åÄ[ÅàÙ-ØùböÍbaØÈmÀøÄY1øèÙtýñQ33EhgiFî'bY?Ët}é
dµ]5ªkÃE{¦s¾}ä
RB¸£wcNÅ62kucHæd½Ò´GÆsÏ!9S(lG¹U:îR'ôRµHÓÓ·då\0j7ÈwÂ^2,ó©
~±×Mr'»O¥PØ0Áè^Ò}ÙwOôE<]CVfÉ4âÔ|Tl^`hÏ]2RÁ²r¬Z¿HcÓ©'M¿FNÜï¨^ì)£·¿:®yµá$X8(Qè6)DÛ!âá%Ááz7ì¾ãd
eý»gä.ÕG²Ñe®fÁIÖçLÈu·0A¦õ(¶EÎêÉî$ÖÜrpPm&1¨0©«×ÎÏFÕÉÁVêmòµ££Ý>[J7É*|¾åkoU|ïFI¾K°³e¶jêc>wýùÅÍ4mLb"äFç9¸Ñ{Gtvüi®l×grõLn,ã08ç3zòj^ZI¾êva#¼ìÇ[eb_w½{5îôü¡
Å».×âÚ,ÞVPkÓl®þOÐþúmòc
ÉF§-8áüs®x®µ*Atöpn|
OÁÏ9ɯëÝpxDmhk¡,ÉPéÙY£QaÉoÖ2:3{\é)B]_ÂK&ð7¢~Y×ð&~FãB¡ÈîÚù^vÄùæ¿#¡àÌ&/ÖKw_a¥vÓÙ.n«zì;ýLó¸îR¿dòdØLE¦Aæ©
ã¨ÁÉ)ÖIC)ëñe`$³M»çÊ3
©þþ~ü_4Ñì^z·è~-DßÅiÁoK07È"S³UÎ"±iÒ\MßBÈÜà".F§»>:)mziG¶¸A²øf°s Yñ0Bß
¹¼¨ù
øÍt¥lJd:õLýiV
fgIª#Y
®üí¯¿ð¼*ÉÔF}åµì£y¬à沧æL
ëcÜ÷7ªÙL)¬®8ãÄ?9Hù8cúÞy:6¬ýÝ´6ºØåüíG½müßçgD¢!¼¾{§!ÈÇxuÚe¤yx²»^ã¸<»i§¿zÄ\%íËxô6#R<ý:ì©./¾ÂY`Õ'×tSýüw$d
ôFÄ-;§¶4åé#pÏ£¨]Ý Gs[o»0×d÷:oyò'§"ê¹QJéâ³ócvì!÷×T
×Ü5QÝ2o2MéòÈ
R¨§8Ä'ôé3²Ùâ
±±Ápa·®e¼G(ábW/]%jT4í V0©ò"¬¢õl
ú¼æ0{ŪË
ALmj
PÐSÅ£Ä*á½8°¸äç°lsÃSÞnc_j¤¿ÌìA¿O¤å.B½¤4åT³Ö·pt
a,&âk3Y6\`*¥0CÜýä³uº¥¥ ¤êÌÔeiÉ춶2ö
zÁÜ/ᥳu³È¡ÂÉr
yY0`¨
æ>QNW»O¤1 Ö»/XëͯN¡G"Hvq§ØtÚæ0Db^JpÄ!(¢`±m©
Vr|;)çbKji:!äѼûiª&«PT¢lÙUý?¡QGÙá²Ö¥}ÒÑYͱQOl-
~êÞ«e9ÝÁë£c&ªm¸ó©Z¹ä]Í×lÒë«Ò7SÕqpD×à¬RE)äZ1¬L÷ðÓZ
3ª_m>é0rmòLB7¨ñÊ]¢_;j½áÛ8MÓ:gS\aÇ&l»±S~·ÔÎdiË?¬,D×WAN§&ÜNÅD
Æ["^IgYJ¿hÃÏ øÂ\©ô5µ«¸}ÌÊ}ÉçÏq¶õ̲3ºôW.
Oqïx´ÕÂRýþT||ɨýr÷û±èÏðÁ¦âWú%,£þeNûÜw·´¾«½?£rz½%ñ"îbX
,ãÈý3eI÷Ø«tRÎÍêtËÊv·¤d(ä^ònz¤ðx¸§ºócÌHìpî¿æo!EØ,¯(zçhõÏÎrb
pÅ¿ÓYÓmÊ÷%÷#u&á%8x&üvÖ%û©5js|0f<úçþ(F6××\*K½½{*È!ÎËÜT÷ìíÕ7G÷*¹>©Ä¾/°Áq
6s_Ïnö¯ü
` ç¶
ýló¾ÎÛqRßV~]«º«rxz¦ìB÷ØÌIh¦è
XkBüÌ®&¬îJ8n_ÐÊÊÂL¾FxÚ{ÍŸk(¿Ëo¥¨ß?Sýþó6ýRÐMÝÉxT9뢼Oé"îÛtÝIÕìçY¬¹È£ûTß:ØIú(à3Àkð7Ü]ëYBQñY$Ö6Rep2L_^Èö
m&
7ôS¡Òïë jX¡6©`_ìÏ]%Õ>²ß5Â^ýìÎ{¯I>TKJK1²YÌ
§àó§"C¥íC2SMî,g,ÕYĸövËøÅT%Â'&[áw!Ó\Â
&]ʨQâKÊýÆÛB¹Ý¸G½ôZø~ÈlôneHl("áRmïD}2D×ô³]eì*j©MÚ!*¹Usã
Mka>¹\ÀÌC88>DXañá°ýÙgKÈÞH¬êï6û¡{KÛo¾;3ÎNðâFãÉÞªj«ÖÕ½´#}þA2Á]¹þúÅÌôÙGî9\µ#LëÅÕ°Ï´Ý©T'ç&Õäì["fÎ1©^W4ãÖø1Ñw?2DzÞk!Ö7çwtí
ç¡h'.IQ,`:ëàcȬ?5Ï,g`7)}Á'uØ-É|ØæRÞî5âh*,¦kÈR8ÔxBÉTL[÷²jíúÎ9)_×2HHåýèfNm[
ëRsÙL²à^ÁÍè²óÕñ?`I>úlgbQvë[qÇØa2ÎDI]6|Br¦Ý¡À?\d
]v¦dOãGâñx¾Çô/L0efS/Øäõ<rõÔ Ò)ü{Ì£.ïwþú°>ý
ÂLÌ¥Vi¤~vH¤.'iØH©vºlà×_©iðl$¯Ê'ÂÍþ|w¹tYþ&¼rR¼$×A7B}¤_ý|ºlû#ÊïËïqªàwR®"[V)³È6fÈßéØhõ«r|çf´
ÇsÚ¹Ä?ø·,§ö1C]Ë$R²HX»ÁUKQV3ªje
JC
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [mointor2 7/9] ovsdb-client: support monitor2
"dev" wrote on 22/10/2015 07:45:29 AM:
>
> Add monito2 option to ovsdb-client. Sed ovsdb-client(1) manpage patch
> for details.
>
> Signed-off-by: Andy Zhou
> ---
...
> static void
> +monitor2_print_row(struct json *row, const char *type, const char
*uuid,
> + const struct ovsdb_column_set *columns, struct table
*t)
> +{
> +if (!strcmp(type, "delete")) {
> +if (row) {
Should be: if (row->type != JSON_NULL) {
> +ovs_error(0, "delete method does not expect ");
> +return;
> +}
> +
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
