Re: [ovs-dev] [PATCH v4 2/2] ofp-monitor: Support flow monitoring for OpenFlow 1.3, 1.4+
Thank you Ilya and Aaron.
Best,
*Vasu Dasari*
On Thu, Apr 28, 2022 at 4:50 PM Ilya Maximets wrote:
> On 4/27/22 17:33, Aaron Conole wrote:
> > Vasu Dasari writes:
> >
> >> Extended OpenFlow monitoring support
> >> * OpenFlow 1.3 with ONF extensions
> >> * OpenFlow 1.4+ as defined in OpenFlow specification 1.4+.
> >>
> >> ONF extensions are similar to Nicira extensions except for
> onf_flow_monitor_request{}
> >> where out_port is defined as 32-bit number OF(1.1) number, oxm match
> formats are
> >> used in update and request messages.
> >>
> >> Flow monitoring support in 1.4+ is slightly different from Nicira and
> ONF
> >> extensions.
> >> * More flow monitoring flags are defined.
> >> * Monitor add/modify/delete command is intruduced in flow_monitor
> >>request message.
> >> * Addition of out_group as part of flow_monitor request message
> >>
> >> Description of changes:
> >> 1. Generate ofp-msgs.inc to be able to support 1.3, 1.4+ flow
> Monitoring messages.
> >> include/openvswitch/ofp-msgs.h
> >>
> >> 2. Modify openflow header files with protocol specific headers.
> >> include/openflow/openflow-1.3.h
> >> include/openflow/openflow-1.4.h
> >>
> >> 3. Modify OvS abstraction of openflow headers. ofp-monitor.h leverages
> enums
> >>from on nicira extensions for creating protocol abstraction headers.
> OF(1.4+)
> >>enums are superset of nicira extensions.
> >> include/openvswitch/ofp-monitor.h
> >>
> >> 4. Changes to these files reflect encoding and decoding of new protocol
> messages.
> >> lib/ofp-monitor.c
> >>
> >> 5. Changes to mmodules using ofp-monitor APIs. Most of the changes here
> are to
> >>migrate enums from nicira to OF 1.4+ versions.
> >> ofproto/connmgr.c
> >> ofproto/connmgr.h
> >> ofproto/ofproto-provider.h
> >> ofproto/ofproto.c
> >>
> >> 6. Extended protocol decoding tests to verify all protocol versions
> >> FLOW_MONITOR_CANCEL
> >> FLOW_MONITOR_PAUSED
> >> FLOW_MONITOR_RESUMED
> >> FLOW_MONITOR request
> >> FLOW_MONITOR reply
> >> tests/ofp-print.at
> >>
> >> 7. Modify flow monitoring tests to be able executed by all protocol
> versions.
> >> tests/ofproto.at
> >>
> >> 7. Modified documentation highlighting the change
> >> utilities/ovs-ofctl.8.in
> >> NEWS
> >>
> >> Signed-off-by: Vasu Dasari
> >> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383915.html
> >> ---
> >
> > Same as previous - looks good, but needs a respin due to NEWS
> >
> > Acked-by: Aaron Conole
>
> Thanks, Vasu. That's a lot of work! Sorry that it took so long.
>
> Thanks, Aaron, for review and reminding me about these patches!
>
> I rebased both patches and applied to master.
>
> Best regards, Ilya Maximets.
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v4 1/2] ofp-monitor: Extend Flow Monitoring support for OF 1.0-1.2 with Nicira Extensions
Currently OVS supports flow-monitoring for OpenFlow 1.0 and Nicira Extenstions.
Any other OpenFlow versioned messages are not accepted. This checkin will allow
OpenFlow1.0-1.2 Flow Monitoring wth Nicira extensions be accepted. Also made
sure that flow-monitoring updates, flow monitoring pause messages, resume
messages are sent in the same OpenFlow version as that of flow-monitor request.
Description of changes:
1. Generate ofp-msgs.inc to be able to support 1.0-1.2 Flow Monitoring messages.
include/openvswitch/ofp-msgs.h
2. Support vconn to accept user specified version and use it for vconn
flow-monitoring session
ofproto/ofproto.c
3. Modify APIs to use protocol as an argument to encode and decode messages
include/openvswitch/ofp-monitor.h
lib/ofp-monitor.c
ofproto/connmgr.c
ofproto/connmgr.h
ofproto/ofproto.c
4. Modified following testcases to be verified across supported OF Versions
ofproto - flow monitoring
ofproto - flow monitoring with !own
ofproto - flow monitoring with out_port
ofproto - flow monitoring pause and resume
ofproto - flow monitoring usable protocols
tests/ofproto.at
5. Updated NEWS with the support added with this commit
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050820.html
---
v1:
- Addressed code review comments from Ben Pfaff:
1. Reduced supported versions from OF 1.0+ to 1.0-1.3 as there is flow
monitoring is supported in OF 1.4+. Need to make changes as part of future
development to add support for OpenFlow 1.4+.
2. Added announcement of this support to NEWS.
3. Extended test cases identified in commit to be tested agains all supported
OF versions.
v2:
- Fix 0-day robot error in NEWS file.
v3:
- Addressed code review comments.
- Reduced OF versions supported to (1.0-1.2).
- Made all flow monitoring tests to be tested against all openflow versions.
- Added an option to dump openflow packets in hex for
add-flow/del-flow/mod-flow.
The option to dump bytes is available for "dump" commands but not for the
flow
management commands. Using this option to be able to generate packets
dynamically
during the flow monitoring tests.
v4:
- Rebased code with latest master.
---
---
AUTHORS.rst | 2 +-
NEWS | 3 +
include/openvswitch/ofp-monitor.h | 9 +-
include/openvswitch/ofp-msgs.h| 4 +-
lib/ofp-monitor.c | 20 ++--
ofproto/connmgr.c | 18 +++-
ofproto/connmgr.h | 3 +-
ofproto/ofproto.c | 13 ++-
tests/ofproto.at | 172 +-
utilities/ovs-ofctl.c | 22 +++-
10 files changed, 160 insertions(+), 106 deletions(-)
diff --git a/AUTHORS.rst b/AUTHORS.rst
index 93a3c30ed..ef4ef996c 100644
--- a/AUTHORS.rst
+++ b/AUTHORS.rst
@@ -420,6 +420,7 @@ Tony van der Peet
tony.vanderp...@alliedtelesis.co.nz
Tonghao Zhang xiangxia.m@gmail.com
Usman Ansari ua1...@gmail.com
Valient Gough vgo...@pobox.com
+Vasu Dasarivdas...@gmail.com
Venkata Anil Kommaddi vkomm...@redhat.com
Vishal Deep Ajmera vishal.deep.ajm...@ericsson.com
Vivien Bernet-Rollande v...@soprive.net
@@ -692,7 +693,6 @@ Tulio Ribeiro tribe...@lasige.di.fc.ul.pt
Tytus Kurek tytus.ku...@pega.com
Valentin Budvalen...@hackaserver.com
Vasiliy Tolstov v.tols...@selfip.ru
-Vasu Dasari vdas...@gmail.com
Vinllen Chencvinl...@gmail.com
Vishal Swarankarvishal.swarn...@gmail.com
Vjekoslav Brajkovic bal...@cs.washington.edu
diff --git a/NEWS b/NEWS
index f5bd79b5a..d8e6c06f7 100644
--- a/NEWS
+++ b/NEWS
@@ -46,6 +46,9 @@ v2.16.0 - 16 Aug 2021
processing database updates.
- In ovs-vsctl and vtep-ctl, the "find" command now accept new
operators {in} and {not-in}.
+ - OpenFlow:
+ * Extend Flow Monitoring support for OpenFlow 1.0-1.2 with Nicira
+ Extensions
- Userspace datapath:
* Auto load balancing of PMDs now partially supports cross-NUMA polling
cases, e.g if all PMD threads are running on the same NUMA node.
diff --git a/include/openvswitch/ofp-monitor.h
b/include/openvswitch/ofp-monitor.h
index 237cef85e..835efd0f3 100644
--- a/include/openvswitch/ofp-monitor.h
+++ b/include/openvswitch/ofp-monitor.h
@@ -70,7 +70,8 @@ struct ofputil_flow_monitor_request {
int ofputil_decode_flow_monitor_request(struct ofputil_flow_monitor_request *,
struct ofpbuf *msg);
void ofputil_append_flow_monitor_request(
-const struct ofputil_flow_monitor_request *, struct ofpbuf *msg);
+const struct ofputil_flow_monitor_request *, struct of
[ovs-dev] [PATCH v4 2/2] ofp-monitor: Support flow monitoring for OpenFlow 1.3, 1.4+
Extended OpenFlow monitoring support
* OpenFlow 1.3 with ONF extensions
* OpenFlow 1.4+ as defined in OpenFlow specification 1.4+.
ONF extensions are similar to Nicira extensions except for
onf_flow_monitor_request{}
where out_port is defined as 32-bit number OF(1.1) number, oxm match formats are
used in update and request messages.
Flow monitoring support in 1.4+ is slightly different from Nicira and ONF
extensions.
* More flow monitoring flags are defined.
* Monitor add/modify/delete command is intruduced in flow_monitor
request message.
* Addition of out_group as part of flow_monitor request message
Description of changes:
1. Generate ofp-msgs.inc to be able to support 1.3, 1.4+ flow Monitoring
messages.
include/openvswitch/ofp-msgs.h
2. Modify openflow header files with protocol specific headers.
include/openflow/openflow-1.3.h
include/openflow/openflow-1.4.h
3. Modify OvS abstraction of openflow headers. ofp-monitor.h leverages enums
from on nicira extensions for creating protocol abstraction headers. OF(1.4+)
enums are superset of nicira extensions.
include/openvswitch/ofp-monitor.h
4. Changes to these files reflect encoding and decoding of new protocol
messages.
lib/ofp-monitor.c
5. Changes to mmodules using ofp-monitor APIs. Most of the changes here are to
migrate enums from nicira to OF 1.4+ versions.
ofproto/connmgr.c
ofproto/connmgr.h
ofproto/ofproto-provider.h
ofproto/ofproto.c
6. Extended protocol decoding tests to verify all protocol versions
FLOW_MONITOR_CANCEL
FLOW_MONITOR_PAUSED
FLOW_MONITOR_RESUMED
FLOW_MONITOR request
FLOW_MONITOR reply
tests/ofp-print.at
7. Modify flow monitoring tests to be able executed by all protocol versions.
tests/ofproto.at
7. Modified documentation highlighting the change
utilities/ovs-ofctl.8.in
NEWS
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383915.html
---
v1:
- Fixed 0-day Robot errors
v4:
- Rebase code with latest master.
---
NEWS | 6 +-
include/openflow/openflow-1.3.h | 89
include/openflow/openflow-1.4.h | 93 +++-
include/openvswitch/ofp-monitor.h | 9 +-
include/openvswitch/ofp-msgs.h| 39 +-
lib/ofp-monitor.c | 844 --
lib/ofp-print.c | 24 +-
ofproto/connmgr.c | 47 +-
ofproto/connmgr.h | 6 +-
ofproto/ofproto-provider.h| 4 +-
ofproto/ofproto.c | 89 +++-
tests/ofp-print.at| 122 -
tests/ofproto.at | 176 +--
utilities/ovs-ofctl.8.in | 3 +
utilities/ovs-ofctl.c | 6 +
15 files changed, 1265 insertions(+), 292 deletions(-)
diff --git a/NEWS b/NEWS
index d8e6c06f7..0555cc8fb 100644
--- a/NEWS
+++ b/NEWS
@@ -47,8 +47,10 @@ v2.16.0 - 16 Aug 2021
- In ovs-vsctl and vtep-ctl, the "find" command now accept new
operators {in} and {not-in}.
- OpenFlow:
- * Extend Flow Monitoring support for OpenFlow 1.0-1.2 with Nicira
- Extensions
+ * Extended Flow Monitoring support for all supported OpenFlow versions
+ OpenFlow versions 1.0-1.2 with Nicira Extensions
+ OpenFlow versions 1.3 with Open Network Foundation extension
+ OpenFlow versions 1.4+, as defined in the OpenFlow specification
- Userspace datapath:
* Auto load balancing of PMDs now partially supports cross-NUMA polling
cases, e.g if all PMD threads are running on the same NUMA node.
diff --git a/include/openflow/openflow-1.3.h b/include/openflow/openflow-1.3.h
index c48a8ea7f..1a818dbb4 100644
--- a/include/openflow/openflow-1.3.h
+++ b/include/openflow/openflow-1.3.h
@@ -374,4 +374,93 @@ struct ofp13_async_config {
};
OFP_ASSERT(sizeof(struct ofp13_async_config) == 24);
+struct onf_flow_monitor_request {
+ovs_be32 id;/* Controller-assigned ID for this monitor. */
+ovs_be16 flags; /* ONFFMF_*. */
+ovs_be16 match_len; /* Length of oxm_fields. */
+ovs_be32 out_port; /* Required output port, if not OFPP_NONE. */
+uint8_ttable_id; /* One table’s ID or 0xff for all tables. */
+uint8_tzeros[3]; /* Align to 64 bits (must be zero). */
+/* Followed by an ofp11_match structure. */
+};
+OFP_ASSERT(sizeof(struct onf_flow_monitor_request) == 16);
+
+/* Header for experimenter requests and replies. */
+struct onf_experimenter_header {
+struct ofp_header header;
+ovs_be32 vendor;/* ONF_EXPERIMENTER_ID. */
+ovs_be32 subtype; /* One of ONFT_*. */
+};
+OFP_ASSERT(sizeof(struct onf_experimenter_header) == 16);
+
+enum onf_flow_monitor_msg_type {
+ONFT_FLOW_MONITOR_CANCEL = 1870,
+ONFT_FLOW_MONITOR_PAUSED = 1871,
+ONFT_FLOW_MONITOR_RESUMED = 1872
+};
+
+/* ’flags’ bits in struct onf_flow_monit
Re: [ovs-dev] [PATCH v2] odp-util: Fix a null pointer dereference in odp_flow_format()
Hi Aaron,
I did not look at your comment before. You are right that, mask_len
parameter is validated via nl_attr_is_valid(). It is ok not to check for
mask_len.
Just that in the function odp_flow_format(), mask_len is used in 3 places.
Two of the places have the check for it and this is the third one that I
suggested to have the check. I am ok with not checking.
Acked-by: Vasu Dasari
Best,
-Vasu
*Vasu Dasari*
On Wed, Sep 1, 2021 at 9:09 AM Aaron Conole wrote:
>
> Hi Vasu,
>
> Vasu Dasari writes:
>
> > Good catch!!!
> > Can you also check for mask_len before calling nl_attr_find__() as is
> done
> > in other places in the same function?
>
> I asked to remove the mask_len check. nl_attr_find__() already does
> such check. I scanned the code to find such examples, but only one
> exists (which is in odp-util.c). Other places either don't validate at
> all, or were pulled during an nl_attr_get_size() call.
>
> I don't see why such check is needed. Maybe I missed something?
>
> > *Vasu Dasari*
> >
> >
> > On Wed, Sep 1, 2021 at 2:29 AM Yunjian Wang
> wrote:
> >
> >> This patch fixes (dereference after null check) coverity issue.
> >> For this reason, we should add null check of 'mask' before calling
> >> nl_attr_find__() because the 'mask' maybe null.
> >>
> >> Addresses-Coverity: ("Dereference after null check")
> >> Fixes: e6cc0babc25d ("ovs-dpctl: Add mega flow support")
> >> Signed-off-by: Yunjian Wang
> >> ---
> >> v2:
> >> * update code styles suggested by Aaron Conole
> >> ---
> >> lib/odp-util.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/lib/odp-util.c b/lib/odp-util.c
> >> index 7729a9060..bf427f027 100644
> >> --- a/lib/odp-util.c
> >> +++ b/lib/odp-util.c
> >> @@ -4618,7 +4618,7 @@ odp_flow_format(const struct nlattr *key, size_t
> >> key_len,
> >> }
> >> ds_put_char(ds, ')');
> >> }
> >> -if (!has_ethtype_key) {
> >> +if (!has_ethtype_key && mask) {
> >> const struct nlattr *ma = nl_attr_find__(mask, mask_len,
> >>
> >> OVS_KEY_ATTR_ETHERTYPE);
> >> if (ma) {
> >> --
> >> 2.18.1
> >>
> >> ___
> >> dev mailing list
> >> d...@openvswitch.org
> >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >>
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] odp-util: Fix a null pointer dereference in odp_flow_format()
Good catch!!!
Can you also check for mask_len before calling nl_attr_find__() as is done
in other places in the same function?
*Vasu Dasari*
On Wed, Sep 1, 2021 at 2:29 AM Yunjian Wang wrote:
> This patch fixes (dereference after null check) coverity issue.
> For this reason, we should add null check of 'mask' before calling
> nl_attr_find__() because the 'mask' maybe null.
>
> Addresses-Coverity: ("Dereference after null check")
> Fixes: e6cc0babc25d ("ovs-dpctl: Add mega flow support")
> Signed-off-by: Yunjian Wang
> ---
> v2:
> * update code styles suggested by Aaron Conole
> ---
> lib/odp-util.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/odp-util.c b/lib/odp-util.c
> index 7729a9060..bf427f027 100644
> --- a/lib/odp-util.c
> +++ b/lib/odp-util.c
> @@ -4618,7 +4618,7 @@ odp_flow_format(const struct nlattr *key, size_t
> key_len,
> }
> ds_put_char(ds, ')');
> }
> -if (!has_ethtype_key) {
> +if (!has_ethtype_key && mask) {
> const struct nlattr *ma = nl_attr_find__(mask, mask_len,
>
> OVS_KEY_ATTR_ETHERTYPE);
> if (ma) {
> --
> 2.18.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1 2/2] ofp-monitor: Support flow monitoring for OpenFlow 1.3, 1.4+
Great, thanks!
*Vasu Dasari*
On Tue, Aug 24, 2021 at 4:11 PM Ashish Varma
wrote:
> I will take a look.
>
> Thanks,
> Ashish
>
> On Tue, Aug 24, 2021 at 9:29 AM Vasu Dasari wrote:
>
>> Hi Ben/Ashish,
>>
>> When you get a chance, Can you please take a look at my code?
>>
>> -Vasu
>>
>> *Vasu Dasari*
>>
>>
>> On Thu, Jul 29, 2021 at 10:36 PM Vasu Dasari wrote:
>>
>>> Extended OpenFlow monitoring support
>>> * OpenFlow 1.3 with ONF extensions
>>> * OpenFlow 1.4+ as defined in OpenFlow specification 1.4+.
>>>
>>> ONF extensions are similar to Nicira extensions except for
>>> onf_flow_monitor_request{}
>>> where out_port is defined as 32-bit number OF(1.1) number, oxm match
>>> formats are
>>> used in update and request messages.
>>>
>>> Flow monitoring support in 1.4+ is slightly different from Nicira and ONF
>>> extensions.
>>> * More flow monitoring flags are defined.
>>> * Monitor add/modify/delete command is intruduced in flow_monitor
>>>request message.
>>> * Addition of out_group as part of flow_monitor request message
>>>
>>> Description of changes:
>>> 1. Generate ofp-msgs.inc to be able to support 1.3, 1.4+ flow Monitoring
>>> messages.
>>> include/openvswitch/ofp-msgs.h
>>>
>>> 2. Modify openflow header files with protocol specific headers.
>>> include/openflow/openflow-1.3.h
>>> include/openflow/openflow-1.4.h
>>>
>>> 3. Modify OvS abstraction of openflow headers. ofp-monitor.h leverages
>>> enums
>>>from on nicira extensions for creating protocol abstraction headers.
>>> OF(1.4+)
>>>enums are superset of nicira extensions.
>>> include/openvswitch/ofp-monitor.h
>>>
>>> 4. Changes to these files reflect encoding and decoding of new protocol
>>> messages.
>>> lib/ofp-monitor.c
>>>
>>> 5. Changes to mmodules using ofp-monitor APIs. Most of the changes here
>>> are to
>>>migrate enums from nicira to OF 1.4+ versions.
>>> ofproto/connmgr.c
>>> ofproto/connmgr.h
>>> ofproto/ofproto-provider.h
>>> ofproto/ofproto.c
>>>
>>> 6. Extended protocol decoding tests to verify all protocol versions
>>> FLOW_MONITOR_CANCEL
>>> FLOW_MONITOR_PAUSED
>>> FLOW_MONITOR_RESUMED
>>> FLOW_MONITOR request
>>> FLOW_MONITOR reply
>>> tests/ofp-print.at
>>>
>>> 7. Modify flow monitoring tests to be able executed by all protocol
>>> versions.
>>> tests/ofproto.at
>>>
>>> 7. Modified documentation highlighting the change
>>> utilities/ovs-ofctl.8.in
>>> NEWS
>>>
>>> Signed-off-by: Vasu Dasari
>>> Reported-at:
>>> https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383915.html
>>> ---
>>> v1:
>>> - Fixed 0-day Robot errors
>>>
>>> ---
>>> NEWS | 6 +-
>>> include/openflow/openflow-1.3.h | 89
>>> include/openflow/openflow-1.4.h | 93 +++-
>>> include/openvswitch/ofp-monitor.h | 9 +-
>>> include/openvswitch/ofp-msgs.h| 39 +-
>>> lib/ofp-monitor.c | 844 --
>>> lib/ofp-print.c | 24 +-
>>> ofproto/connmgr.c | 47 +-
>>> ofproto/connmgr.h | 6 +-
>>> ofproto/ofproto-provider.h| 4 +-
>>> ofproto/ofproto.c | 89 +++-
>>> tests/ofp-print.at| 122 -
>>> tests/ofproto.at | 176 +--
>>> utilities/ovs-ofctl.8.in | 3 +
>>> utilities/ovs-ofctl.c | 6 +
>>> 15 files changed, 1265 insertions(+), 292 deletions(-)
>>>
>>> diff --git a/NEWS b/NEWS
>>> index 02884b774..47ad9de2a 100644
>>> --- a/NEWS
>>> +++ b/NEWS
>>> @@ -25,8 +25,10 @@ v2.16.0 - xx xxx
>>> - In ovs-vsctl and vtep-ctl, the "find" command now accept new
>>> operators {in} and {not-in}.
>>> - OpenFlow:
>>> - * Extend Flow Monitoring support for OpenFlow 1.0-1.2 with Nicira
>>> - Extensions
>>> + * Extended Flow Monitoring support for all supported OpenFlow
>>> versions
>>> + OpenFlow versions 1.0-1.2 with Nicir
Re: [ovs-dev] [PATCH v1 2/2] ofp-monitor: Support flow monitoring for OpenFlow 1.3, 1.4+
Hi Ben/Ashish,
When you get a chance, Can you please take a look at my code?
-Vasu
*Vasu Dasari*
On Thu, Jul 29, 2021 at 10:36 PM Vasu Dasari wrote:
> Extended OpenFlow monitoring support
> * OpenFlow 1.3 with ONF extensions
> * OpenFlow 1.4+ as defined in OpenFlow specification 1.4+.
>
> ONF extensions are similar to Nicira extensions except for
> onf_flow_monitor_request{}
> where out_port is defined as 32-bit number OF(1.1) number, oxm match
> formats are
> used in update and request messages.
>
> Flow monitoring support in 1.4+ is slightly different from Nicira and ONF
> extensions.
> * More flow monitoring flags are defined.
> * Monitor add/modify/delete command is intruduced in flow_monitor
>request message.
> * Addition of out_group as part of flow_monitor request message
>
> Description of changes:
> 1. Generate ofp-msgs.inc to be able to support 1.3, 1.4+ flow Monitoring
> messages.
> include/openvswitch/ofp-msgs.h
>
> 2. Modify openflow header files with protocol specific headers.
> include/openflow/openflow-1.3.h
> include/openflow/openflow-1.4.h
>
> 3. Modify OvS abstraction of openflow headers. ofp-monitor.h leverages
> enums
>from on nicira extensions for creating protocol abstraction headers.
> OF(1.4+)
>enums are superset of nicira extensions.
> include/openvswitch/ofp-monitor.h
>
> 4. Changes to these files reflect encoding and decoding of new protocol
> messages.
> lib/ofp-monitor.c
>
> 5. Changes to mmodules using ofp-monitor APIs. Most of the changes here
> are to
>migrate enums from nicira to OF 1.4+ versions.
> ofproto/connmgr.c
> ofproto/connmgr.h
> ofproto/ofproto-provider.h
> ofproto/ofproto.c
>
> 6. Extended protocol decoding tests to verify all protocol versions
> FLOW_MONITOR_CANCEL
> FLOW_MONITOR_PAUSED
> FLOW_MONITOR_RESUMED
> FLOW_MONITOR request
> FLOW_MONITOR reply
> tests/ofp-print.at
>
> 7. Modify flow monitoring tests to be able executed by all protocol
> versions.
> tests/ofproto.at
>
> 7. Modified documentation highlighting the change
> utilities/ovs-ofctl.8.in
> NEWS
>
> Signed-off-by: Vasu Dasari
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383915.html
> ---
> v1:
> - Fixed 0-day Robot errors
>
> ---
> NEWS | 6 +-
> include/openflow/openflow-1.3.h | 89
> include/openflow/openflow-1.4.h | 93 +++-
> include/openvswitch/ofp-monitor.h | 9 +-
> include/openvswitch/ofp-msgs.h| 39 +-
> lib/ofp-monitor.c | 844 --
> lib/ofp-print.c | 24 +-
> ofproto/connmgr.c | 47 +-
> ofproto/connmgr.h | 6 +-
> ofproto/ofproto-provider.h| 4 +-
> ofproto/ofproto.c | 89 +++-
> tests/ofp-print.at| 122 -
> tests/ofproto.at | 176 +--
> utilities/ovs-ofctl.8.in | 3 +
> utilities/ovs-ofctl.c | 6 +
> 15 files changed, 1265 insertions(+), 292 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 02884b774..47ad9de2a 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -25,8 +25,10 @@ v2.16.0 - xx xxx
> - In ovs-vsctl and vtep-ctl, the "find" command now accept new
> operators {in} and {not-in}.
> - OpenFlow:
> - * Extend Flow Monitoring support for OpenFlow 1.0-1.2 with Nicira
> - Extensions
> + * Extended Flow Monitoring support for all supported OpenFlow
> versions
> + OpenFlow versions 1.0-1.2 with Nicira Extensions
> + OpenFlow versions 1.3 with Open Network Foundation extension
> + OpenFlow versions 1.4+, as defined in the OpenFlow specification
> - Userspace datapath:
> * Auto load balancing of PMDs now partially supports cross-NUMA
> polling
> cases, e.g if all PMD threads are running on the same NUMA node.
> diff --git a/include/openflow/openflow-1.3.h
> b/include/openflow/openflow-1.3.h
> index c48a8ea7f..1a818dbb4 100644
> --- a/include/openflow/openflow-1.3.h
> +++ b/include/openflow/openflow-1.3.h
> @@ -374,4 +374,93 @@ struct ofp13_async_config {
> };
> OFP_ASSERT(sizeof(struct ofp13_async_config) == 24);
>
> +struct onf_flow_monitor_request {
> +ovs_be32 id;/* Controller-assigned ID for this monitor.
> */
> +ovs_be16 flags; /* ONFFMF_*. */
> +ovs_be16 match_len; /* Length of oxm_fields. */
> +ovs_be32 out_port; /* Required output port, if not OFPP_NONE.
> */
> +uint8_ttable_id; /* One table
[ovs-dev] [PATCH v1 2/2] ofp-monitor: Support flow monitoring for OpenFlow 1.3, 1.4+
Extended OpenFlow monitoring support
* OpenFlow 1.3 with ONF extensions
* OpenFlow 1.4+ as defined in OpenFlow specification 1.4+.
ONF extensions are similar to Nicira extensions except for
onf_flow_monitor_request{}
where out_port is defined as 32-bit number OF(1.1) number, oxm match formats are
used in update and request messages.
Flow monitoring support in 1.4+ is slightly different from Nicira and ONF
extensions.
* More flow monitoring flags are defined.
* Monitor add/modify/delete command is intruduced in flow_monitor
request message.
* Addition of out_group as part of flow_monitor request message
Description of changes:
1. Generate ofp-msgs.inc to be able to support 1.3, 1.4+ flow Monitoring
messages.
include/openvswitch/ofp-msgs.h
2. Modify openflow header files with protocol specific headers.
include/openflow/openflow-1.3.h
include/openflow/openflow-1.4.h
3. Modify OvS abstraction of openflow headers. ofp-monitor.h leverages enums
from on nicira extensions for creating protocol abstraction headers. OF(1.4+)
enums are superset of nicira extensions.
include/openvswitch/ofp-monitor.h
4. Changes to these files reflect encoding and decoding of new protocol
messages.
lib/ofp-monitor.c
5. Changes to mmodules using ofp-monitor APIs. Most of the changes here are to
migrate enums from nicira to OF 1.4+ versions.
ofproto/connmgr.c
ofproto/connmgr.h
ofproto/ofproto-provider.h
ofproto/ofproto.c
6. Extended protocol decoding tests to verify all protocol versions
FLOW_MONITOR_CANCEL
FLOW_MONITOR_PAUSED
FLOW_MONITOR_RESUMED
FLOW_MONITOR request
FLOW_MONITOR reply
tests/ofp-print.at
7. Modify flow monitoring tests to be able executed by all protocol versions.
tests/ofproto.at
7. Modified documentation highlighting the change
utilities/ovs-ofctl.8.in
NEWS
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383915.html
---
v1:
- Fixed 0-day Robot errors
---
NEWS | 6 +-
include/openflow/openflow-1.3.h | 89
include/openflow/openflow-1.4.h | 93 +++-
include/openvswitch/ofp-monitor.h | 9 +-
include/openvswitch/ofp-msgs.h| 39 +-
lib/ofp-monitor.c | 844 --
lib/ofp-print.c | 24 +-
ofproto/connmgr.c | 47 +-
ofproto/connmgr.h | 6 +-
ofproto/ofproto-provider.h| 4 +-
ofproto/ofproto.c | 89 +++-
tests/ofp-print.at| 122 -
tests/ofproto.at | 176 +--
utilities/ovs-ofctl.8.in | 3 +
utilities/ovs-ofctl.c | 6 +
15 files changed, 1265 insertions(+), 292 deletions(-)
diff --git a/NEWS b/NEWS
index 02884b774..47ad9de2a 100644
--- a/NEWS
+++ b/NEWS
@@ -25,8 +25,10 @@ v2.16.0 - xx xxx
- In ovs-vsctl and vtep-ctl, the "find" command now accept new
operators {in} and {not-in}.
- OpenFlow:
- * Extend Flow Monitoring support for OpenFlow 1.0-1.2 with Nicira
- Extensions
+ * Extended Flow Monitoring support for all supported OpenFlow versions
+ OpenFlow versions 1.0-1.2 with Nicira Extensions
+ OpenFlow versions 1.3 with Open Network Foundation extension
+ OpenFlow versions 1.4+, as defined in the OpenFlow specification
- Userspace datapath:
* Auto load balancing of PMDs now partially supports cross-NUMA polling
cases, e.g if all PMD threads are running on the same NUMA node.
diff --git a/include/openflow/openflow-1.3.h b/include/openflow/openflow-1.3.h
index c48a8ea7f..1a818dbb4 100644
--- a/include/openflow/openflow-1.3.h
+++ b/include/openflow/openflow-1.3.h
@@ -374,4 +374,93 @@ struct ofp13_async_config {
};
OFP_ASSERT(sizeof(struct ofp13_async_config) == 24);
+struct onf_flow_monitor_request {
+ovs_be32 id;/* Controller-assigned ID for this monitor. */
+ovs_be16 flags; /* ONFFMF_*. */
+ovs_be16 match_len; /* Length of oxm_fields. */
+ovs_be32 out_port; /* Required output port, if not OFPP_NONE. */
+uint8_ttable_id; /* One table’s ID or 0xff for all tables. */
+uint8_tzeros[3]; /* Align to 64 bits (must be zero). */
+/* Followed by an ofp11_match structure. */
+};
+OFP_ASSERT(sizeof(struct onf_flow_monitor_request) == 16);
+
+/* Header for experimenter requests and replies. */
+struct onf_experimenter_header {
+struct ofp_header header;
+ovs_be32 vendor;/* ONF_EXPERIMENTER_ID. */
+ovs_be32 subtype; /* One of ONFT_*. */
+};
+OFP_ASSERT(sizeof(struct onf_experimenter_header) == 16);
+
+enum onf_flow_monitor_msg_type {
+ONFT_FLOW_MONITOR_CANCEL = 1870,
+ONFT_FLOW_MONITOR_PAUSED = 1871,
+ONFT_FLOW_MONITOR_RESUMED = 1872
+};
+
+/* ’flags’ bits in struct onf_flow_monitor_request. */
+enum onf_flow_monitor_flags {
+
Re: [ovs-dev] [PATCH 2/2] ofp-monitor: Support flow monitoring for OpenFlow 1.3, 1.4+
Hi Ashish,
Here is the patch that supports flow monitoring for 1.3 and 1.4+.
I have taken test case to test out_group from your patch
<http://patchwork.ozlabs.org/project/openvswitch/patch/1548978579-28929-1-git-send-email-ashishvarma@gmail.com/>
that you shared privately. I wish I had known the existence of your patch,
it would have made it a lot easier to support 1.4+ versions.
Thanks
-Vasu
*Vasu Dasari*
On Thu, Jul 29, 2021 at 7:54 PM Vasu Dasari wrote:
> Extended OpenFlow monitoring support
> * OpenFlow 1.3 with ONF extensions
> * OpenFlow 1.4+ as defined in OpenFlow specification 1.4+.
>
> ONF extensions are similar to Nicira extensions except for
> onf_flow_monitor_request{}
> where out_port is defined as 32-bit number OF(1.1) number, oxm match
> formats are
> used in update and request messages.
>
> Flow monitoring support in 1.4+ is slightly different from Nicira and ONF
> extensions.
> * More flow monitoring flags are defined.
> * Monitor add/modify/delete command is intruduced in flow_monitor
>request message.
> * Addition of out_group as part of flow_monitor request message
>
> Description of changes:
> 1. Generate ofp-msgs.inc to be able to support 1.3, 1.4+ flow Monitoring
> messages.
> include/openvswitch/ofp-msgs.h
>
> 2. Modify openflow header files with protocol specific headers.
> include/openflow/openflow-1.3.h
> include/openflow/openflow-1.4.h
>
> 3. Modify OvS abstraction of openflow headers. ofp-monitor.h leverages
> enums
>from on nicira extensions for creating protocol abstraction headers.
> OF(1.4+)
>enums are superset of nicira extensions.
> include/openvswitch/ofp-monitor.h
>
> 4. Changes to these files reflect encoding and decoding of new protocol
> messages.
> lib/ofp-monitor.c
>
> 5. Changes to mmodules using ofp-monitor APIs. Most of the changes here
> are to
>migrate enums from nicira to OF 1.4+ versions.
> ofproto/connmgr.c
> ofproto/connmgr.h
> ofproto/ofproto-provider.h
> ofproto/ofproto.c
>
> 6. Extended protocol decoding tests to verify all protocol versions
> FLOW_MONITOR_CANCEL
> FLOW_MONITOR_PAUSED
> FLOW_MONITOR_RESUMED
> FLOW_MONITOR request
> FLOW_MONITOR reply
> tests/ofp-print.at
>
> 7. Modify flow monitoring tests to be able executed by all protocol
> versions.
> tests/ofproto.at
>
> 7. Modified documentation highlighting the change
> utilities/ovs-ofctl.8.in
> NEWS
>
> Signed-off-by: Vasu Dasari
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383915.html
> ---
> NEWS | 6 +-
> include/openflow/openflow-1.3.h | 89
> include/openflow/openflow-1.4.h | 93 +++-
> include/openvswitch/ofp-monitor.h | 9 +-
> include/openvswitch/ofp-msgs.h| 39 +-
> lib/ofp-monitor.c | 844 --
> lib/ofp-print.c | 24 +-
> ofproto/connmgr.c | 47 +-
> ofproto/connmgr.h | 6 +-
> ofproto/ofproto-provider.h| 4 +-
> ofproto/ofproto.c | 89 +++-
> tests/ofp-print.at| 122 -
> tests/ofproto.at | 176 +--
> utilities/ovs-ofctl.8.in | 3 +
> utilities/ovs-ofctl.c | 6 +
> 15 files changed, 1265 insertions(+), 292 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 02884b774..47ad9de2a 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -25,8 +25,10 @@ v2.16.0 - xx xxx
> - In ovs-vsctl and vtep-ctl, the "find" command now accept new
> operators {in} and {not-in}.
> - OpenFlow:
> - * Extend Flow Monitoring support for OpenFlow 1.0-1.2 with Nicira
> - Extensions
> + * Extended Flow Monitoring support for all supported OpenFlow
> versions
> + OpenFlow versions 1.0-1.2 with Nicira Extensions
> + OpenFlow versions 1.3 with Open Network Foundation extension
> + OpenFlow versions 1.4+, as defined in the OpenFlow specification
> - Userspace datapath:
> * Auto load balancing of PMDs now partially supports cross-NUMA
> polling
> cases, e.g if all PMD threads are running on the same NUMA node.
> diff --git a/include/openflow/openflow-1.3.h
> b/include/openflow/openflow-1.3.h
> index c48a8ea7f..1a818dbb4 100644
> --- a/include/openflow/openflow-1.3.h
> +++ b/include/openflow/openflow-1.3.h
> @@ -374,4 +374,93 @@ struct ofp13_async_config {
> };
> OFP_ASSERT(sizeof(struct ofp13_async_config) == 24);
>
> +struct onf_flow_monitor_request {
> +ovs_be32 id;/* Controller-assigned ID for th
Re: [ovs-dev] [PATCH 1/2] ofp-monitor: Extend Flow Monitoring support for OF 1.0-1.2 with Nicira Extensions
Hi Ben,
I am converting individual patch
<http://patchwork.ozlabs.org/project/openvswitch/patch/20210614034931.12245-1-vdas...@gmail.com/>,
which you briefly looked at earlier, to the first one in a series of
patches. Second patch 2/2 depends on this codebase.
Thanks
-Vasu
*Vasu Dasari*
On Thu, Jul 29, 2021 at 7:54 PM Vasu Dasari wrote:
> Currently OVS supports flow-monitoring for OpenFlow 1.0 and Nicira
> Extenstions.
> Any other OpenFlow versioned messages are not accepted. This checkin will
> allow
> OpenFlow1.0-1.2 Flow Monitoring wth Nicira extensions be accepted. Also
> made
> sure that flow-monitoring updates, flow monitoring pause messages, resume
> messages are sent in the same OpenFlow version as that of flow-monitor
> request.
>
> Description of changes:
>
> 1. Generate ofp-msgs.inc to be able to support 1.0-1.2 Flow Monitoring
> messages.
> include/openvswitch/ofp-msgs.h
>
> 2. Support vconn to accept user specified version and use it for vconn
> flow-monitoring session
> ofproto/ofproto.c
>
> 3. Modify APIs to use protocol as an argument to encode and decode messages
> include/openvswitch/ofp-monitor.h
> lib/ofp-monitor.c
> ofproto/connmgr.c
> ofproto/connmgr.h
> ofproto/ofproto.c
>
> 4. Modified following testcases to be verified across supported OF Versions
> ofproto - flow monitoring
> ofproto - flow monitoring with !own
> ofproto - flow monitoring with out_port
> ofproto - flow monitoring pause and resume
> ofproto - flow monitoring usable protocols
> tests/ofproto.at
>
> 5. Updated NEWS with the support added with this commit
>
> Signed-off-by: Vasu Dasari
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050820.html
> ---
>
> v1:
> - Addressed code review comments from Ben Pfaff:
> 1. Reduced supported versions from OF 1.0+ to 1.0-1.3 as there is flow
> monitoring is supported in OF 1.4+. Need to make changes as part of
> future
> development to add support for OpenFlow 1.4+
> 2. Added announcement of this support to NEWS
> 3. Extended test cases identified in commit to be tested agains all
> supported
> OF versions.
> v2:
> - Fix 0-day robot error in NEWS file
> v3:
> - Addressed code review comments
> - Reduced OF versions supported to (1.0-1.2)
> - Made all flow monitoring tests to be tested against all openflow
> versions
> - Added an option to dump openflow packets in hex for
> add-flow/del-flow/mod-flow.
>The option to dump bytes is available for "dump" commands but not for
> the flow
>management commands. Using this option to be able to generate packets
> dynamically
>during the flow monitoring tests
> ---
> ---
> AUTHORS.rst | 2 +-
> NEWS | 3 +
> include/openvswitch/ofp-monitor.h | 9 +-
> include/openvswitch/ofp-msgs.h| 4 +-
> lib/ofp-monitor.c | 20 ++--
> ofproto/connmgr.c | 18 +++-
> ofproto/connmgr.h | 3 +-
> ofproto/ofproto.c | 13 ++-
> tests/ofproto.at | 172 +-
> utilities/ovs-ofctl.c | 22 +++-
> 10 files changed, 160 insertions(+), 106 deletions(-)
>
> diff --git a/AUTHORS.rst b/AUTHORS.rst
> index 092e92cdf..da16b537d 100644
> --- a/AUTHORS.rst
> +++ b/AUTHORS.rst
> @@ -413,6 +413,7 @@ Tony van der Peet
> tony.vanderp...@alliedtelesis.co.nz
> Tonghao Zhang xiangxia.m@gmail.com
> Usman Ansari ua1...@gmail.com
> Valient Gough vgo...@pobox.com
> +Vasu Dasarivdas...@gmail.com
> Venkata Anil Kommaddi vkomm...@redhat.com
> Vishal Deep Ajmera vishal.deep.ajm...@ericsson.com
> Vivien Bernet-Rollande v...@soprive.net
> @@ -683,7 +684,6 @@ Tulio Ribeiro
> tribe...@lasige.di.fc.ul.pt
> Tytus Kurek tytus.ku...@pega.com
> Valentin Budvalen...@hackaserver.com
> Vasiliy Tolstov v.tols...@selfip.ru
> -Vasu Dasari vdas...@gmail.com
> Vinllen Chencvinl...@gmail.com
> Vishal Swarankarvishal.swarn...@gmail.com
> Vjekoslav Brajkovic bal...@cs.washington.edu
> diff --git a/NEWS b/NEWS
> index 75045b67d..02884b774 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -24,6 +24,9 @@ v2.16.0 - xx xxx
> processing database updates.
> - In ovs-vsctl and vtep-ctl, the "find" command now accept new
> operators {in} and {not-in}.
> + - OpenFlow:
> + * Extend Flow Monitoring
[ovs-dev] [PATCH 2/2] ofp-monitor: Support flow monitoring for OpenFlow 1.3, 1.4+
Extended OpenFlow monitoring support
* OpenFlow 1.3 with ONF extensions
* OpenFlow 1.4+ as defined in OpenFlow specification 1.4+.
ONF extensions are similar to Nicira extensions except for
onf_flow_monitor_request{}
where out_port is defined as 32-bit number OF(1.1) number, oxm match formats are
used in update and request messages.
Flow monitoring support in 1.4+ is slightly different from Nicira and ONF
extensions.
* More flow monitoring flags are defined.
* Monitor add/modify/delete command is intruduced in flow_monitor
request message.
* Addition of out_group as part of flow_monitor request message
Description of changes:
1. Generate ofp-msgs.inc to be able to support 1.3, 1.4+ flow Monitoring
messages.
include/openvswitch/ofp-msgs.h
2. Modify openflow header files with protocol specific headers.
include/openflow/openflow-1.3.h
include/openflow/openflow-1.4.h
3. Modify OvS abstraction of openflow headers. ofp-monitor.h leverages enums
from on nicira extensions for creating protocol abstraction headers. OF(1.4+)
enums are superset of nicira extensions.
include/openvswitch/ofp-monitor.h
4. Changes to these files reflect encoding and decoding of new protocol
messages.
lib/ofp-monitor.c
5. Changes to mmodules using ofp-monitor APIs. Most of the changes here are to
migrate enums from nicira to OF 1.4+ versions.
ofproto/connmgr.c
ofproto/connmgr.h
ofproto/ofproto-provider.h
ofproto/ofproto.c
6. Extended protocol decoding tests to verify all protocol versions
FLOW_MONITOR_CANCEL
FLOW_MONITOR_PAUSED
FLOW_MONITOR_RESUMED
FLOW_MONITOR request
FLOW_MONITOR reply
tests/ofp-print.at
7. Modify flow monitoring tests to be able executed by all protocol versions.
tests/ofproto.at
7. Modified documentation highlighting the change
utilities/ovs-ofctl.8.in
NEWS
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383915.html
---
NEWS | 6 +-
include/openflow/openflow-1.3.h | 89
include/openflow/openflow-1.4.h | 93 +++-
include/openvswitch/ofp-monitor.h | 9 +-
include/openvswitch/ofp-msgs.h| 39 +-
lib/ofp-monitor.c | 844 --
lib/ofp-print.c | 24 +-
ofproto/connmgr.c | 47 +-
ofproto/connmgr.h | 6 +-
ofproto/ofproto-provider.h| 4 +-
ofproto/ofproto.c | 89 +++-
tests/ofp-print.at| 122 -
tests/ofproto.at | 176 +--
utilities/ovs-ofctl.8.in | 3 +
utilities/ovs-ofctl.c | 6 +
15 files changed, 1265 insertions(+), 292 deletions(-)
diff --git a/NEWS b/NEWS
index 02884b774..47ad9de2a 100644
--- a/NEWS
+++ b/NEWS
@@ -25,8 +25,10 @@ v2.16.0 - xx xxx
- In ovs-vsctl and vtep-ctl, the "find" command now accept new
operators {in} and {not-in}.
- OpenFlow:
- * Extend Flow Monitoring support for OpenFlow 1.0-1.2 with Nicira
- Extensions
+ * Extended Flow Monitoring support for all supported OpenFlow versions
+ OpenFlow versions 1.0-1.2 with Nicira Extensions
+ OpenFlow versions 1.3 with Open Network Foundation extension
+ OpenFlow versions 1.4+, as defined in the OpenFlow specification
- Userspace datapath:
* Auto load balancing of PMDs now partially supports cross-NUMA polling
cases, e.g if all PMD threads are running on the same NUMA node.
diff --git a/include/openflow/openflow-1.3.h b/include/openflow/openflow-1.3.h
index c48a8ea7f..1a818dbb4 100644
--- a/include/openflow/openflow-1.3.h
+++ b/include/openflow/openflow-1.3.h
@@ -374,4 +374,93 @@ struct ofp13_async_config {
};
OFP_ASSERT(sizeof(struct ofp13_async_config) == 24);
+struct onf_flow_monitor_request {
+ovs_be32 id;/* Controller-assigned ID for this monitor. */
+ovs_be16 flags; /* ONFFMF_*. */
+ovs_be16 match_len; /* Length of oxm_fields. */
+ovs_be32 out_port; /* Required output port, if not OFPP_NONE. */
+uint8_ttable_id; /* One table’s ID or 0xff for all tables. */
+uint8_tzeros[3]; /* Align to 64 bits (must be zero). */
+/* Followed by an ofp11_match structure. */
+};
+OFP_ASSERT(sizeof(struct onf_flow_monitor_request) == 16);
+
+/* Header for experimenter requests and replies. */
+struct onf_experimenter_header {
+struct ofp_header header;
+ovs_be32 vendor;/* ONF_EXPERIMENTER_ID. */
+ovs_be32 subtype; /* One of ONFT_*. */
+};
+OFP_ASSERT(sizeof(struct onf_experimenter_header) == 16);
+
+enum onf_flow_monitor_msg_type {
+ONFT_FLOW_MONITOR_CANCEL = 1870,
+ONFT_FLOW_MONITOR_PAUSED = 1871,
+ONFT_FLOW_MONITOR_RESUMED = 1872
+};
+
+/* ’flags’ bits in struct onf_flow_monitor_request. */
+enum onf_flow_monitor_flags {
+/* When to se
[ovs-dev] [PATCH 1/2] ofp-monitor: Extend Flow Monitoring support for OF 1.0-1.2 with Nicira Extensions
Currently OVS supports flow-monitoring for OpenFlow 1.0 and Nicira Extenstions.
Any other OpenFlow versioned messages are not accepted. This checkin will allow
OpenFlow1.0-1.2 Flow Monitoring wth Nicira extensions be accepted. Also made
sure that flow-monitoring updates, flow monitoring pause messages, resume
messages are sent in the same OpenFlow version as that of flow-monitor request.
Description of changes:
1. Generate ofp-msgs.inc to be able to support 1.0-1.2 Flow Monitoring messages.
include/openvswitch/ofp-msgs.h
2. Support vconn to accept user specified version and use it for vconn
flow-monitoring session
ofproto/ofproto.c
3. Modify APIs to use protocol as an argument to encode and decode messages
include/openvswitch/ofp-monitor.h
lib/ofp-monitor.c
ofproto/connmgr.c
ofproto/connmgr.h
ofproto/ofproto.c
4. Modified following testcases to be verified across supported OF Versions
ofproto - flow monitoring
ofproto - flow monitoring with !own
ofproto - flow monitoring with out_port
ofproto - flow monitoring pause and resume
ofproto - flow monitoring usable protocols
tests/ofproto.at
5. Updated NEWS with the support added with this commit
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050820.html
---
v1:
- Addressed code review comments from Ben Pfaff:
1. Reduced supported versions from OF 1.0+ to 1.0-1.3 as there is flow
monitoring is supported in OF 1.4+. Need to make changes as part of future
development to add support for OpenFlow 1.4+
2. Added announcement of this support to NEWS
3. Extended test cases identified in commit to be tested agains all supported
OF versions.
v2:
- Fix 0-day robot error in NEWS file
v3:
- Addressed code review comments
- Reduced OF versions supported to (1.0-1.2)
- Made all flow monitoring tests to be tested against all openflow versions
- Added an option to dump openflow packets in hex for
add-flow/del-flow/mod-flow.
The option to dump bytes is available for "dump" commands but not for the
flow
management commands. Using this option to be able to generate packets
dynamically
during the flow monitoring tests
---
---
AUTHORS.rst | 2 +-
NEWS | 3 +
include/openvswitch/ofp-monitor.h | 9 +-
include/openvswitch/ofp-msgs.h| 4 +-
lib/ofp-monitor.c | 20 ++--
ofproto/connmgr.c | 18 +++-
ofproto/connmgr.h | 3 +-
ofproto/ofproto.c | 13 ++-
tests/ofproto.at | 172 +-
utilities/ovs-ofctl.c | 22 +++-
10 files changed, 160 insertions(+), 106 deletions(-)
diff --git a/AUTHORS.rst b/AUTHORS.rst
index 092e92cdf..da16b537d 100644
--- a/AUTHORS.rst
+++ b/AUTHORS.rst
@@ -413,6 +413,7 @@ Tony van der Peet
tony.vanderp...@alliedtelesis.co.nz
Tonghao Zhang xiangxia.m@gmail.com
Usman Ansari ua1...@gmail.com
Valient Gough vgo...@pobox.com
+Vasu Dasarivdas...@gmail.com
Venkata Anil Kommaddi vkomm...@redhat.com
Vishal Deep Ajmera vishal.deep.ajm...@ericsson.com
Vivien Bernet-Rollande v...@soprive.net
@@ -683,7 +684,6 @@ Tulio Ribeiro tribe...@lasige.di.fc.ul.pt
Tytus Kurek tytus.ku...@pega.com
Valentin Budvalen...@hackaserver.com
Vasiliy Tolstov v.tols...@selfip.ru
-Vasu Dasari vdas...@gmail.com
Vinllen Chencvinl...@gmail.com
Vishal Swarankarvishal.swarn...@gmail.com
Vjekoslav Brajkovic bal...@cs.washington.edu
diff --git a/NEWS b/NEWS
index 75045b67d..02884b774 100644
--- a/NEWS
+++ b/NEWS
@@ -24,6 +24,9 @@ v2.16.0 - xx xxx
processing database updates.
- In ovs-vsctl and vtep-ctl, the "find" command now accept new
operators {in} and {not-in}.
+ - OpenFlow:
+ * Extend Flow Monitoring support for OpenFlow 1.0-1.2 with Nicira
+ Extensions
- Userspace datapath:
* Auto load balancing of PMDs now partially supports cross-NUMA polling
cases, e.g if all PMD threads are running on the same NUMA node.
diff --git a/include/openvswitch/ofp-monitor.h
b/include/openvswitch/ofp-monitor.h
index 237cef85e..835efd0f3 100644
--- a/include/openvswitch/ofp-monitor.h
+++ b/include/openvswitch/ofp-monitor.h
@@ -70,7 +70,8 @@ struct ofputil_flow_monitor_request {
int ofputil_decode_flow_monitor_request(struct ofputil_flow_monitor_request *,
struct ofpbuf *msg);
void ofputil_append_flow_monitor_request(
-const struct ofputil_flow_monitor_request *, struct ofpbuf *msg);
+const struct ofputil_flow_monitor_request *, struct ofpbuf *msg,
+enum ofputil_proto
Re: [ovs-dev] [PATCH v10] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Hi Eelco/Ben, I found that the documentation for ovs-vswitchd did not reflect the last minute change I made to the fdb/del syntax. This last patch v11 <https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/384632.html> version reflects that change. Thanks -Vasu *Vasu Dasari* On Tue, Jun 29, 2021 at 3:54 PM Vasu Dasari wrote: > Thank you Eelco for your careful review. I appreciate and thank you for > all your comments. > > -Vasu > > *Vasu Dasari* > > > On Tue, Jun 29, 2021 at 11:08 AM Eelco Chaudron > wrote: > >> >> >> On 29 Jun 2021, at 15:19, Vasu Dasari wrote: >> >> > Currently there is an option to add/flush/show ARP/ND neighbor. This >> covers L3 >> > side. For L2 side, there is only fdb show command. This patch gives an >> option >> > to add/del an fdb entry via ovs-appctl. >> > >> > CLI command looks like: >> > >> > To add: >> > ovs-appctl fdb/add >> > ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05 >> > >> > To del: >> > ovs-appctl fdb/del >> > ovs-appctl fdb/del br0 0 50:54:00:00:00:05 >> > >> > Added two new APIs to provide convenient interface to add and delete >> static-macs. >> > bool xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t >> in_port, >> >struct eth_addr dl_src, int vlan); >> > bool xlate_delete_static_mac_entry(const struct ofproto_dpif *, >> > struct eth_addr dl_src, int vlan); >> > >> > 1. Static entry should not age. To indicate that entry being programmed >> is a static entry, >> >'expires' field in 'struct mac_entry' will be set to a >> MAC_ENTRY_AGE_STATIC_ENTRY. A >> >check for this value is made while deleting mac entry as part of >> regular aging process. >> > 2. Another change to of mac-update logic, when a packet with same >> dl_src as that of a >> >static-mac entry arrives on any port, the logic will not modify the >> expires field. >> > 3. While flushing fdb entries, made sure static ones are not evicted. >> > 4. Updated "ovs-appctl fdb/stats-show br0" to display numberof static >> entries in switch >> > >> > Added following tests: >> > ofproto-dpif - static-mac add/del/flush >> > ofproto-dpif - static-mac mac moves >> > >> > Signed-off-by: Vasu Dasari >> > Reported-at: >> https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html >> > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752 >> > Tested-by: Eelco Chaudron >> > Acked-by: Eelco Chaudron >> > --- >> >> Thanks for your patience to follow this trough! >> >> Acked-by: Eelco Chaudron >> >> //Eelco >> >> ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v11] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Currently there is an option to add/flush/show ARP/ND neighbor. This covers L3
side. For L2 side, there is only fdb show command. This patch gives an option
to add/del an fdb entry via ovs-appctl.
CLI command looks like:
To add:
ovs-appctl fdb/add
ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05
To del:
ovs-appctl fdb/del
ovs-appctl fdb/del br0 0 50:54:00:00:00:05
Added two new APIs to provide convenient interface to add and delete
static-macs.
bool xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t in_port,
struct eth_addr dl_src, int vlan);
bool xlate_delete_static_mac_entry(const struct ofproto_dpif *,
struct eth_addr dl_src, int vlan);
1. Static entry should not age. To indicate that entry being programmed is a
static entry,
'expires' field in 'struct mac_entry' will be set to a
MAC_ENTRY_AGE_STATIC_ENTRY. A
check for this value is made while deleting mac entry as part of regular
aging process.
2. Another change to of mac-update logic, when a packet with same dl_src as
that of a
static-mac entry arrives on any port, the logic will not modify the expires
field.
3. While flushing fdb entries, made sure static ones are not evicted.
4. Updated "ovs-appctl fdb/stats-show br0" to display numberof static entries
in switch
Added following tests:
ofproto-dpif - static-mac add/del/flush
ofproto-dpif - static-mac mac moves
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752
Tested-by: Eelco Chaudron
Acked-by: Eelco Chaudron
---
v1:
- Fixed 0-day robot warnings
v2:
- Fix valgrind error in the modified code in mac_learning_insert() where a
read is
is performed on e->expires which is not initialized
v3:
- Addressed code review comments
- Added more documentation
- Fixed mac_entry_age() and is_mac_learning_update_needed() to have common
understanding of return values when mac_entry is a static one.
- Added NEWS item
v4:
- Addressed code review comments
- Static entries will not be purged when fdb/flush is performed.
- Static entries will not be overwritten when packet with same dl_src arrives
on
any port of switch
- Provided bit more detail while doing fdb/add, to indicate if static-mac is
overriding already present entry
- Separated test cases for a bit more clarity
v5:
- Addressed code review comments
- Added new total_static counter to count number of static entries.
- Removed mac_entry_set_idle_time()
- Added mac_learning_add_static_entry() and mac_learning_del_static_entry()
- Modified APIs xlate_add_static_mac_entry() and
xlate_delete_static_mac_entry()
return 0 on success else a failure code
v6:
- Fixed a probable bug with Eelco's code review comments in
is_mac_learning_update_needed()
v7:
- Added a ovs-vswitchd.8 man page entry for fdb add/del commands
v8:
- Updaed with code review comments from Eelco.
- Renamed total_static to static_entries
- Added coverage counter mac_learning_static_none_move
- Fixed a possible bug with static_entries getting cleared via
fdb/stats-clear command
- Initialize static_entries in mac_learning_create()
- Modified fdb/del command by removing option to specify port-name
- Breakup ofproto_unixctl_fdb_update into ofproto_unixctl_fdb_add
and ofproto_unixctl_fdb_delete
- Updated test "static-mac add/del/flush" to have interleaved mac
entries before fdb/flush
- Updated test "static-mac mac move" to check for newly added
coverage counter mac_learning_static_none_move
v9:
- Updated source code comments and addressed code review comments
v10:
- Simplified error code paths in ofproto_unixctl_fdb_{add,delete}
functions
v11:
- Fix ovs-vswitchd man page documentation to reflect changed syntax
---
NEWS | 4 +
lib/mac-learning.c | 155 +++
lib/mac-learning.h | 17
ofproto/ofproto-dpif-xlate.c | 48 +--
ofproto/ofproto-dpif-xlate.h | 5 ++
ofproto/ofproto-dpif.c | 111 -
tests/ofproto-dpif.at| 99 ++
vswitchd/ovs-vswitchd.8.in | 6 ++
8 files changed, 416 insertions(+), 29 deletions(-)
diff --git a/NEWS b/NEWS
index f02f07cdf..909e88c6d 100644
--- a/NEWS
+++ b/NEWS
@@ -25,6 +25,10 @@ Post-v2.15.0
- ovsdb-tool:
* New option '--election-timer' to the 'create-cluster' command to set the
leader election timer during cluster creation.
+ - ovs-appctl:
+ * Added ability to add and delete static mac entries using:
+ 'ovs-appctl fdb/add'
+ 'ovs-appctl fdb/del '
v2.15.0 - 15 Feb 2021
diff --git a/lib/mac-learning.c b/lib/mac-learning.c
index 3d5293d3b..dd3f46a8b 100644
--- a/lib/mac-learning.c
+++ b/lib/mac-learning.c
@@ -34,13 +34,25 @@ COV
Re: [ovs-dev] [PATCH v10] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Thank you Eelco for your careful review. I appreciate and thank you for all your comments. -Vasu *Vasu Dasari* On Tue, Jun 29, 2021 at 11:08 AM Eelco Chaudron wrote: > > > On 29 Jun 2021, at 15:19, Vasu Dasari wrote: > > > Currently there is an option to add/flush/show ARP/ND neighbor. This > covers L3 > > side. For L2 side, there is only fdb show command. This patch gives an > option > > to add/del an fdb entry via ovs-appctl. > > > > CLI command looks like: > > > > To add: > > ovs-appctl fdb/add > > ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05 > > > > To del: > > ovs-appctl fdb/del > > ovs-appctl fdb/del br0 0 50:54:00:00:00:05 > > > > Added two new APIs to provide convenient interface to add and delete > static-macs. > > bool xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t > in_port, > >struct eth_addr dl_src, int vlan); > > bool xlate_delete_static_mac_entry(const struct ofproto_dpif *, > > struct eth_addr dl_src, int vlan); > > > > 1. Static entry should not age. To indicate that entry being programmed > is a static entry, > >'expires' field in 'struct mac_entry' will be set to a > MAC_ENTRY_AGE_STATIC_ENTRY. A > >check for this value is made while deleting mac entry as part of > regular aging process. > > 2. Another change to of mac-update logic, when a packet with same dl_src > as that of a > >static-mac entry arrives on any port, the logic will not modify the > expires field. > > 3. While flushing fdb entries, made sure static ones are not evicted. > > 4. Updated "ovs-appctl fdb/stats-show br0" to display numberof static > entries in switch > > > > Added following tests: > > ofproto-dpif - static-mac add/del/flush > > ofproto-dpif - static-mac mac moves > > > > Signed-off-by: Vasu Dasari > > Reported-at: > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html > > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752 > > Tested-by: Eelco Chaudron > > Acked-by: Eelco Chaudron > > --- > > Thanks for your patience to follow this trough! > > Acked-by: Eelco Chaudron > > //Eelco > > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v10] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Currently there is an option to add/flush/show ARP/ND neighbor. This covers L3
side. For L2 side, there is only fdb show command. This patch gives an option
to add/del an fdb entry via ovs-appctl.
CLI command looks like:
To add:
ovs-appctl fdb/add
ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05
To del:
ovs-appctl fdb/del
ovs-appctl fdb/del br0 0 50:54:00:00:00:05
Added two new APIs to provide convenient interface to add and delete
static-macs.
bool xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t in_port,
struct eth_addr dl_src, int vlan);
bool xlate_delete_static_mac_entry(const struct ofproto_dpif *,
struct eth_addr dl_src, int vlan);
1. Static entry should not age. To indicate that entry being programmed is a
static entry,
'expires' field in 'struct mac_entry' will be set to a
MAC_ENTRY_AGE_STATIC_ENTRY. A
check for this value is made while deleting mac entry as part of regular
aging process.
2. Another change to of mac-update logic, when a packet with same dl_src as
that of a
static-mac entry arrives on any port, the logic will not modify the expires
field.
3. While flushing fdb entries, made sure static ones are not evicted.
4. Updated "ovs-appctl fdb/stats-show br0" to display numberof static entries
in switch
Added following tests:
ofproto-dpif - static-mac add/del/flush
ofproto-dpif - static-mac mac moves
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752
Tested-by: Eelco Chaudron
Acked-by: Eelco Chaudron
---
v1:
- Fixed 0-day robot warnings
v2:
- Fix valgrind error in the modified code in mac_learning_insert() where a
read is
is performed on e->expires which is not initialized
v3:
- Addressed code review comments
- Added more documentation
- Fixed mac_entry_age() and is_mac_learning_update_needed() to have common
understanding of return values when mac_entry is a static one.
- Added NEWS item
v4:
- Addressed code review comments
- Static entries will not be purged when fdb/flush is performed.
- Static entries will not be overwritten when packet with same dl_src arrives
on
any port of switch
- Provided bit more detail while doing fdb/add, to indicate if static-mac is
overriding already present entry
- Separated test cases for a bit more clarity
v5:
- Addressed code review comments
- Added new total_static counter to count number of static entries.
- Removed mac_entry_set_idle_time()
- Added mac_learning_add_static_entry() and mac_learning_del_static_entry()
- Modified APIs xlate_add_static_mac_entry() and
xlate_delete_static_mac_entry()
return 0 on success else a failure code
v6:
- Fixed a probable bug with Eelco's code review comments in
is_mac_learning_update_needed()
v7:
- Added a ovs-vswitchd.8 man page entry for fdb add/del commands
v8:
- Updaed with code review comments from Eelco.
- Renamed total_static to static_entries
- Added coverage counter mac_learning_static_none_move
- Fixed a possible bug with static_entries getting cleared via
fdb/stats-clear command
- Initialize static_entries in mac_learning_create()
- Modified fdb/del command by removing option to specify port-name
- Breakup ofproto_unixctl_fdb_update into ofproto_unixctl_fdb_add
and ofproto_unixctl_fdb_delete
- Updated test "static-mac add/del/flush" to have interleaved mac
entries before fdb/flush
- Updated test "static-mac mac move" to check for newly added
coverage counter mac_learning_static_none_move
v9:
- Updated source code comments and addressed code review comments
v10:
- Simplified error code paths in ofproto_unixctl_fdb_{add,delete}
functions
---
NEWS | 4 +
lib/mac-learning.c | 155 +++
lib/mac-learning.h | 17
ofproto/ofproto-dpif-xlate.c | 48 +--
ofproto/ofproto-dpif-xlate.h | 5 ++
ofproto/ofproto-dpif.c | 111 -
tests/ofproto-dpif.at| 99 ++
vswitchd/ovs-vswitchd.8.in | 5 ++
8 files changed, 415 insertions(+), 29 deletions(-)
diff --git a/NEWS b/NEWS
index f02f07cdf..909e88c6d 100644
--- a/NEWS
+++ b/NEWS
@@ -25,6 +25,10 @@ Post-v2.15.0
- ovsdb-tool:
* New option '--election-timer' to the 'create-cluster' command to set the
leader election timer during cluster creation.
+ - ovs-appctl:
+ * Added ability to add and delete static mac entries using:
+ 'ovs-appctl fdb/add'
+ 'ovs-appctl fdb/del '
v2.15.0 - 15 Feb 2021
diff --git a/lib/mac-learning.c b/lib/mac-learning.c
index 3d5293d3b..dd3f46a8b 100644
--- a/lib/mac-learning.c
+++ b/lib/mac-learning.c
@@ -34,13 +34,25 @@ COVERAGE_DEFINE(mac_learning_learned);
COVERAGE_DEFINE(mac_le
Re: [ovs-dev] [PATCH v9] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Hi Eelco. Thanks for the review. Will update with your suggestions. I am out of town. Will do this next week. Thanks Vasu > On Jun 25, 2021, at 8:55 AM, Eelco Chaudron wrote: > > > This one looks good, however, I would make some small changes. > If you do, you can add my acked by to the new revision. > > //Eelco > > On 24 Jun 2021, at 17:57, Vasu Dasari wrote: > > Currently there is an option to add/flush/show ARP/ND neighbor. This covers > L3 > side. For L2 side, there is only fdb show command. This patch gives an option > to add/del an fdb entry via ovs-appctl. > > CLI command looks like: > > To add: > ovs-appctl fdb/add > ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05 > > To del: > ovs-appctl fdb/del > ovs-appctl fdb/del br0 0 50:54:00:00:00:05 > > Added two new APIs to provide convenient interface to add and delete > static-macs. > bool xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t > in_port, > struct eth_addr dl_src, int vlan); > bool xlate_delete_static_mac_entry(const struct ofproto_dpif *, > struct eth_addr dl_src, int vlan); > > 1. Static entry should not age. To indicate that entry being programmed is a > static entry, > 'expires' field in 'struct mac_entry' will be set to a > MAC_ENTRY_AGE_STATIC_ENTRY. A > check for this value is made while deleting mac entry as part of regular > aging process. > 2. Another change to of mac-update logic, when a packet with same dl_src as > that of a > static-mac entry arrives on any port, the logic will not modify the expires > field. > 3. While flushing fdb entries, made sure static ones are not evicted. > 4. Updated "ovs-appctl fdb/stats-show br0" to display numberof static entries > in switch > > Added following tests: > ofproto-dpif - static-mac add/del/flush > ofproto-dpif - static-mac mac moves > > Signed-off-by: Vasu Dasari > Reported-at: > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752 > Tested-by: Eelco Chaudron > --- > v1: > - Fixed 0-day robot warnings > v2: > - Fix valgrind error in the modified code in mac_learning_insert() where a > read is > is performed on e->expires which is not initialized > v3: > - Addressed code review comments > - Added more documentation > - Fixed mac_entry_age() and is_mac_learning_update_needed() to have common > understanding of return values when mac_entry is a static one. > - Added NEWS item > v4: > - Addressed code review comments > - Static entries will not be purged when fdb/flush is performed. > - Static entries will not be overwritten when packet with same dl_src arrives > on > any port of switch > - Provided bit more detail while doing fdb/add, to indicate if static-mac is > overriding already present entry > - Separated test cases for a bit more clarity > v5: > - Addressed code review comments > - Added new total_static counter to count number of static entries. > - Removed mac_entry_set_idle_time() > - Added mac_learning_add_static_entry() and mac_learning_del_static_entry() > - Modified APIs xlate_add_static_mac_entry() and > xlate_delete_static_mac_entry() > return 0 on success else a failure code > v6: > - Fixed a probable bug with Eelco's code review comments in > is_mac_learning_update_needed() > v7: > - Added a ovs-vswitchd.8 man page entry for fdb add/del commands > v8: > - Updaed with code review comments from Eelco. > - Renamed total_static to static_entries > - Added coverage counter mac_learning_static_none_move > - Fixed a possible bug with static_entries getting cleared via > fdb/stats-clear command > - Initialize static_entries in mac_learning_create() > - Modified fdb/del command by removing option to specify port-name > - Breakup ofproto_unixctl_fdb_update into ofproto_unixctl_fdb_add > and ofproto_unixctl_fdb_delete > - Updated test "static-mac add/del/flush" to have interleaved mac > entries before fdb/flush > - Updated test "static-mac mac move" to check for newly added > coverage counter mac_learning_static_none_move > v9: > - Updated source code comments and addressed code review comments > --- > NEWS | 4 + > lib/mac-learning.c | 155 +++ > lib/mac-learning.h | 17 > ofproto/ofproto-dpif-xlate.c | 48 +-- > ofproto/ofproto-dpif-xlate.h | 5 ++ > ofproto/ofproto-dpif.c | 117 +- > tests/ofproto-dpif.at | 99 ++ > vswitchd/ovs-vswitchd.8.in | 5 ++ > 8 files changed, 421 insertions(+), 29 deletions(-)
Re: [ovs-dev] [PATCH v8] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Thank you Eelco for a patient review. I have addressed all your comments, also fixed comments in test files as well. Here is the Patch v9 <https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/384417.html>. Thanks -Vasu *Vasu Dasari* On Thu, Jun 24, 2021 at 8:16 AM Eelco Chaudron wrote: > Thanks Vasu for the quick turnaround! I found some very small issues. If > you could fix those, I can ack the patch! > > Cheers, > > Eelco > > On 24 Jun 2021, at 12:52, Vasu Dasari wrote: > > > Currently there is an option to add/flush/show ARP/ND neighbor. This > covers L3 > > side. For L2 side, there is only fdb show command. This patch gives an > option > > to add/del an fdb entry via ovs-appctl. > > > > CLI command looks like: > > > > To add: > > ovs-appctl fdb/add > > ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05 > > > > To del: > > ovs-appctl fdb/del > > ovs-appctl fdb/del br0 0 50:54:00:00:00:05 > > > > Added two new APIs to provide convenient interface to add and delete > static-macs. > > bool xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t > in_port, > >struct eth_addr dl_src, int vlan); > > bool xlate_delete_static_mac_entry(const struct ofproto_dpif *, > > struct eth_addr dl_src, int vlan); > > > > 1. Static entry should not age. To indicate that entry being programmed > is a static entry, > >'expires' field in 'struct mac_entry' will be set to a > MAC_ENTRY_AGE_STATIC_ENTRY. A > >check for this value is made while deleting mac entry as part of > regular aging process. > > 2. Another change to of mac-update logic, when a packet with same dl_src > as that of a > >static-mac entry arrives on any port, the logic will not modify the > expires field. > > 3. While flushing fdb entries, made sure static ones are not evicted. > > 4. Updated "ovs-appctl fdb/stats-show br0" to display numberof static > entries in switch > > > > Added following tests: > > ofproto-dpif - static-mac add/del/flush > > ofproto-dpif - static-mac mac moves > > > > Signed-off-by: Vasu Dasari > > Reported-at: > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html > > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752 > > Tested-by: Eelco Chaudron > > --- > > v1: > > - Fixed 0-day robot warnings > > v2: > > - Fix valgrind error in the modified code in mac_learning_insert() > where a read is > >is performed on e->expires which is not initialized > > v3: > > - Addressed code review comments > > - Added more documentation > > - Fixed mac_entry_age() and is_mac_learning_update_needed() to have > common > >understanding of return values when mac_entry is a static one. > > - Added NEWS item > > v4: > > - Addressed code review comments > > - Static entries will not be purged when fdb/flush is performed. > > - Static entries will not be overwritten when packet with same dl_src > arrives on > >any port of switch > > - Provided bit more detail while doing fdb/add, to indicate if > static-mac is > >overriding already present entry > > - Separated test cases for a bit more clarity > > v5: > > - Addressed code review comments > > - Added new total_static counter to count number of static entries. > > - Removed mac_entry_set_idle_time() > > - Added mac_learning_add_static_entry() and > mac_learning_del_static_entry() > > - Modified APIs xlate_add_static_mac_entry() and > xlate_delete_static_mac_entry() > >return 0 on success else a failure code > > v6: > > - Fixed a probable bug with Eelco's code review comments in > >is_mac_learning_update_needed() > > v7: > > - Added a ovs-vswitchd.8 man page entry for fdb add/del commands > > v8: > > - Updaed with code review comments from Eelco. > > - Renamed total_static to static_entries > > - Added coverage counter mac_learning_static_none_move > > - Fixed a possible bug with static_entries getting cleared via > >fdb/stats-clear command > > - Initialize static_entries in mac_learning_create() > > - Modified fdb/del command by removing option to specify port-name > > - Breakup ofproto_unixctl_fdb_update into ofproto_unixctl_fdb_add > >and ofproto_unixctl_fdb_delete > > - Updated test "static-mac add/del/flush" to have interleaved mac > >entries before fdb/flush > > - Updated test "static-mac mac m
[ovs-dev] [PATCH v9] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Currently there is an option to add/flush/show ARP/ND neighbor. This covers L3 side. For L2 side, there is only fdb show command. This patch gives an option to add/del an fdb entry via ovs-appctl. CLI command looks like: To add: ovs-appctl fdb/add ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05 To del: ovs-appctl fdb/del ovs-appctl fdb/del br0 0 50:54:00:00:00:05 Added two new APIs to provide convenient interface to add and delete static-macs. bool xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t in_port, struct eth_addr dl_src, int vlan); bool xlate_delete_static_mac_entry(const struct ofproto_dpif *, struct eth_addr dl_src, int vlan); 1. Static entry should not age. To indicate that entry being programmed is a static entry, 'expires' field in 'struct mac_entry' will be set to a MAC_ENTRY_AGE_STATIC_ENTRY. A check for this value is made while deleting mac entry as part of regular aging process. 2. Another change to of mac-update logic, when a packet with same dl_src as that of a static-mac entry arrives on any port, the logic will not modify the expires field. 3. While flushing fdb entries, made sure static ones are not evicted. 4. Updated "ovs-appctl fdb/stats-show br0" to display numberof static entries in switch Added following tests: ofproto-dpif - static-mac add/del/flush ofproto-dpif - static-mac mac moves Signed-off-by: Vasu Dasari Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752 Tested-by: Eelco Chaudron --- v1: - Fixed 0-day robot warnings v2: - Fix valgrind error in the modified code in mac_learning_insert() where a read is is performed on e->expires which is not initialized v3: - Addressed code review comments - Added more documentation - Fixed mac_entry_age() and is_mac_learning_update_needed() to have common understanding of return values when mac_entry is a static one. - Added NEWS item v4: - Addressed code review comments - Static entries will not be purged when fdb/flush is performed. - Static entries will not be overwritten when packet with same dl_src arrives on any port of switch - Provided bit more detail while doing fdb/add, to indicate if static-mac is overriding already present entry - Separated test cases for a bit more clarity v5: - Addressed code review comments - Added new total_static counter to count number of static entries. - Removed mac_entry_set_idle_time() - Added mac_learning_add_static_entry() and mac_learning_del_static_entry() - Modified APIs xlate_add_static_mac_entry() and xlate_delete_static_mac_entry() return 0 on success else a failure code v6: - Fixed a probable bug with Eelco's code review comments in is_mac_learning_update_needed() v7: - Added a ovs-vswitchd.8 man page entry for fdb add/del commands v8: - Updaed with code review comments from Eelco. - Renamed total_static to static_entries - Added coverage counter mac_learning_static_none_move - Fixed a possible bug with static_entries getting cleared via fdb/stats-clear command - Initialize static_entries in mac_learning_create() - Modified fdb/del command by removing option to specify port-name - Breakup ofproto_unixctl_fdb_update into ofproto_unixctl_fdb_add and ofproto_unixctl_fdb_delete - Updated test "static-mac add/del/flush" to have interleaved mac entries before fdb/flush - Updated test "static-mac mac move" to check for newly added coverage counter mac_learning_static_none_move v9: - Updated source code comments and addressed code review comments --- NEWS | 4 + lib/mac-learning.c | 155 +++ lib/mac-learning.h | 17 ofproto/ofproto-dpif-xlate.c | 48 +-- ofproto/ofproto-dpif-xlate.h | 5 ++ ofproto/ofproto-dpif.c | 117 +- tests/ofproto-dpif.at| 99 ++ vswitchd/ovs-vswitchd.8.in | 5 ++ 8 files changed, 421 insertions(+), 29 deletions(-) diff --git a/NEWS b/NEWS index db3faf4cc..12fb40054 100644 --- a/NEWS +++ b/NEWS @@ -20,6 +20,10 @@ Post-v2.15.0 - ovsdb-tool: * New option '--election-timer' to the 'create-cluster' command to set the leader election timer during cluster creation. + - ovs-appctl: + * Added ability to add and delete static mac entries using: + 'ovs-appctl fdb/add' + 'ovs-appctl fdb/del ' v2.15.0 - 15 Feb 2021 diff --git a/lib/mac-learning.c b/lib/mac-learning.c index 3d5293d3b..dd3f46a8b 100644 --- a/lib/mac-learning.c +++ b/lib/mac-learning.c @@ -34,13 +34,25 @@ COVERAGE_DEFINE(mac_learning_learned); COVERAGE_DEFINE(mac_learning_expired); COVERAGE_DEFINE(mac_learning_evicted); COVERAGE_DEFINE(mac_learning_moved); +COVERAGE_DEFINE(mac_learning
Re: [ovs-dev] [PATCH v6] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Hi Eelco, Thank you for a thorough review. I have Ack'd all comments and created a patch at Patch v8 <https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/384363.html>. My comments inline: (Mostly all Acks) Thanks -Vasu *Vasu Dasari* On Wed, Jun 23, 2021 at 10:41 AM Eelco Chaudron wrote: > > On 12 Jun 2021, at 4:09, Vasu Dasari wrote: > > See my inline comments below. > > Cheers, > > Eelco > > > > Currently there is an option to add/flush/show ARP/ND neighbor. This > covers L3 > > side. For L2 side, there is only fdb show command. This patch gives an > option > > to add/del an fdb entry via ovs-appctl. > > > > CLI command looks like: > > > > To add: > > ovs-appctl fdb/add > > ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05 > > > > To del: > > ovs-appctl fdb/del > > ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05 > > > > Added two new APIs to provide convenient interface to add and delete > static-macs. > > bool xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t > in_port, > >struct eth_addr dl_src, int vlan); > > bool xlate_delete_static_mac_entry(const struct ofproto_dpif *, > > struct eth_addr dl_src, int vlan); > > > > 1. Static entry should not age. To indicate that entry being programmed > is a static entry, > >'expires' field in 'struct mac_entry' will be set to a > MAC_ENTRY_AGE_STATIC_ENTRY. A > >check for this value is made while deleting mac entry as part of > regular aging process. > > 2. Another change to of mac-update logic, when a packet with same dl_src > as that of a > >static-mac entry arrives on any port, the logic will not modify the > expires field. > > 3. While flushing fdb entries, made sure static ones are not evicted. > > 4. Updated "ovs-appctl fdb/stats-show br0" to display numberof static > entries in switch > > > > Added following tests: > > ofproto-dpif - static-mac add/del/flush > > ofproto-dpif - static-mac mac moves > > > > Signed-off-by: Vasu Dasari > > Reported-at: > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html > > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752 > > Tested-by: Eelco Chaudron > > --- > > v1: > > - Fixed 0-day robot warnings > > v2: > > - Fix valgrind error in the modified code in mac_learning_insert() > where a read is > >is performed on e->expires which is not initialized > > v3: > > - Addressed code review comments > > - Added more documentation > > - Fixed mac_entry_age() and is_mac_learning_update_needed() to have > common > >understanding of return values when mac_entry is a static one. > > - Added NEWS item > > v4: > > - Addressed code review comments > > - Static entries will not be purged when fdb/flush is performed. > > - Static entries will not be overwritten when packet with same dl_src > arrives on > >any port of switch > > - Provided bit more detail while doing fdb/add, to indicate if > static-mac is > >overriding already present entry > > - Separated test cases for a bit more clarity > > v5: > > - Addressed code review comments > > - Added new total_static counter to count number of static entries. > > - Removed mac_entry_set_idle_time() > > - Added mac_learning_add_static_entry() and > mac_learning_del_static_entry() > > - Modified APIs xlate_add_static_mac_entry() and > xlate_delete_static_mac_entry() > >return 0 on success else a failure code > > v6: > > - Fixed a probable bug with Eelco's code review comments in > >is_mac_learning_update_needed() > > --- > > NEWS | 2 + > > lib/mac-learning.c | 149 +++ > > lib/mac-learning.h | 17 > > ofproto/ofproto-dpif-xlate.c | 48 +-- > > ofproto/ofproto-dpif-xlate.h | 5 ++ > > ofproto/ofproto-dpif.c | 95 +- > > tests/ofproto-dpif.at| 93 ++ > > 7 files changed, 380 insertions(+), 29 deletions(-) > > > > diff --git a/NEWS b/NEWS > > index ebba17b22..501b26cee 100644 > > --- a/NEWS > > +++ b/NEWS > > @@ -9,6 +9,8 @@ Post-v2.15.0 > > - Userspace datapath: > > * Auto load balancing of PMDs now partially supports cross-NUMA > polling > > cases, e.g if all PMD threads are running on the same NUMA node. > > +
[ovs-dev] [PATCH v8] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Currently there is an option to add/flush/show ARP/ND neighbor. This covers L3 side. For L2 side, there is only fdb show command. This patch gives an option to add/del an fdb entry via ovs-appctl. CLI command looks like: To add: ovs-appctl fdb/add ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05 To del: ovs-appctl fdb/del ovs-appctl fdb/del br0 0 50:54:00:00:00:05 Added two new APIs to provide convenient interface to add and delete static-macs. bool xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t in_port, struct eth_addr dl_src, int vlan); bool xlate_delete_static_mac_entry(const struct ofproto_dpif *, struct eth_addr dl_src, int vlan); 1. Static entry should not age. To indicate that entry being programmed is a static entry, 'expires' field in 'struct mac_entry' will be set to a MAC_ENTRY_AGE_STATIC_ENTRY. A check for this value is made while deleting mac entry as part of regular aging process. 2. Another change to of mac-update logic, when a packet with same dl_src as that of a static-mac entry arrives on any port, the logic will not modify the expires field. 3. While flushing fdb entries, made sure static ones are not evicted. 4. Updated "ovs-appctl fdb/stats-show br0" to display numberof static entries in switch Added following tests: ofproto-dpif - static-mac add/del/flush ofproto-dpif - static-mac mac moves Signed-off-by: Vasu Dasari Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752 Tested-by: Eelco Chaudron --- v1: - Fixed 0-day robot warnings v2: - Fix valgrind error in the modified code in mac_learning_insert() where a read is is performed on e->expires which is not initialized v3: - Addressed code review comments - Added more documentation - Fixed mac_entry_age() and is_mac_learning_update_needed() to have common understanding of return values when mac_entry is a static one. - Added NEWS item v4: - Addressed code review comments - Static entries will not be purged when fdb/flush is performed. - Static entries will not be overwritten when packet with same dl_src arrives on any port of switch - Provided bit more detail while doing fdb/add, to indicate if static-mac is overriding already present entry - Separated test cases for a bit more clarity v5: - Addressed code review comments - Added new total_static counter to count number of static entries. - Removed mac_entry_set_idle_time() - Added mac_learning_add_static_entry() and mac_learning_del_static_entry() - Modified APIs xlate_add_static_mac_entry() and xlate_delete_static_mac_entry() return 0 on success else a failure code v6: - Fixed a probable bug with Eelco's code review comments in is_mac_learning_update_needed() v7: - Added a ovs-vswitchd.8 man page entry for fdb add/del commands v8: - Updaed with code review comments from Eelco. - Renamed total_static to static_entries - Added coverage counter mac_learning_static_none_move - Fixed a possible bug with static_entries getting cleared via fdb/stats-clear command - Initialize static_entries in mac_learning_create() - Modified fdb/del command by removing option to specify port-name - Breakup ofproto_unixctl_fdb_update into ofproto_unixctl_fdb_add and ofproto_unixctl_fdb_delete - Updated test "static-mac add/del/flush" to have interleaved mac entries before fdb/flush - Updated test "static-mac mac move" to check for newly added coverage counter mac_learning_static_none_move --- NEWS | 4 + lib/mac-learning.c | 155 +++ lib/mac-learning.h | 17 ofproto/ofproto-dpif-xlate.c | 48 +-- ofproto/ofproto-dpif-xlate.h | 5 ++ ofproto/ofproto-dpif.c | 114 +- tests/ofproto-dpif.at| 99 ++ vswitchd/ovs-vswitchd.8.in | 5 ++ 8 files changed, 418 insertions(+), 29 deletions(-) diff --git a/NEWS b/NEWS index db3faf4cc..12fb40054 100644 --- a/NEWS +++ b/NEWS @@ -20,6 +20,10 @@ Post-v2.15.0 - ovsdb-tool: * New option '--election-timer' to the 'create-cluster' command to set the leader election timer during cluster creation. + - ovs-appctl: + * Added ability to add and delete static mac entries using: + 'ovs-appctl fdb/add' + 'ovs-appctl fdb/del ' v2.15.0 - 15 Feb 2021 diff --git a/lib/mac-learning.c b/lib/mac-learning.c index 3d5293d3b..234ac7d33 100644 --- a/lib/mac-learning.c +++ b/lib/mac-learning.c @@ -34,13 +34,25 @@ COVERAGE_DEFINE(mac_learning_learned); COVERAGE_DEFINE(mac_learning_expired); COVERAGE_DEFINE(mac_learning_evicted); COVERAGE_DEFINE(mac_learning_moved); +COVERAGE_DEFINE(mac_learning_static_none_move); -/* Returns the number of seconds since '
[ovs-dev] [PATCH v7] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Currently there is an option to add/flush/show ARP/ND neighbor. This covers L3
side. For L2 side, there is only fdb show command. This patch gives an option
to add/del an fdb entry via ovs-appctl.
CLI command looks like:
To add:
ovs-appctl fdb/add
ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05
To del:
ovs-appctl fdb/del
ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05
Added two new APIs to provide convenient interface to add and delete
static-macs.
bool xlate_add_static_mac_entry(const struct ofproto_dpif *,
ofp_port_t in_port,
struct eth_addr dl_src, int vlan);
bool xlate_delete_static_mac_entry(const struct ofproto_dpif *,
struct eth_addr dl_src, int vlan);
1. Static entry should not age. To indicate that entry being programmed is a
static entry, 'expires' field in 'struct mac_entry' will be set to a
MAC_ENTRY_AGE_STATIC_ENTRY. A check for this value is made while deleting
mac entry as part of regular aging process.
2. Another change to of mac-update logic, when a packet with same dl_src as
that of a static-mac entry arrives on any port, the logic will not modify
the expires field.
3. While flushing fdb entries, made sure static ones are not evicted.
4. Updated "ovs-appctl fdb/stats-show br0" to display numberof static entries
in switch
Added following tests:
ofproto-dpif - static-mac add/del/flush
ofproto-dpif - static-mac mac moves
Added to NEWS about this functionality. Updated ovs-vswitchd man page with
CLI commands.
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752
Tested-by: Eelco Chaudron
---
v1:
- Fixed 0-day robot warnings
v2:
- Fix valgrind error in the modified code in mac_learning_insert() where a
read is
is performed on e->expires which is not initialized
v3:
- Addressed code review comments
- Added more documentation
- Fixed mac_entry_age() and is_mac_learning_update_needed() to have common
understanding of return values when mac_entry is a static one.
- Added NEWS item
v4:
- Addressed code review comments
- Static entries will not be purged when fdb/flush is performed.
- Static entries will not be overwritten when packet with same dl_src arrives
on
any port of switch
- Provided bit more detail while doing fdb/add, to indicate if static-mac is
overriding already present entry
- Separated test cases for a bit more clarity
v5:
- Addressed code review comments
- Added new total_static counter to count number of static entries.
- Removed mac_entry_set_idle_time()
- Added mac_learning_add_static_entry() and mac_learning_del_static_entry()
- Modified APIs xlate_add_static_mac_entry() and
xlate_delete_static_mac_entry()
return 0 on success else a failure code
v6:
- Fixed a probable bug with Eelco's code review comments in
is_mac_learning_update_needed()
v7:
- Added a ovs-vswitchd.8 man page entry for fdb add/del commands
---
NEWS | 2 +
lib/mac-learning.c | 151 +++
lib/mac-learning.h | 17
ofproto/ofproto-dpif-xlate.c | 48 +--
ofproto/ofproto-dpif-xlate.h | 5 ++
ofproto/ofproto-dpif.c | 95 +-
tests/ofproto-dpif.at| 93 +
vswitchd/ovs-vswitchd.8.in | 5 ++
8 files changed, 387 insertions(+), 29 deletions(-)
diff --git a/NEWS b/NEWS
index ebba17b22..501b26cee 100644
--- a/NEWS
+++ b/NEWS
@@ -9,6 +9,8 @@ Post-v2.15.0
- Userspace datapath:
* Auto load balancing of PMDs now partially supports cross-NUMA polling
cases, e.g if all PMD threads are running on the same NUMA node.
+ * Added ability to add and delete static mac entries using:
+ 'ovs-appctl fdb/{add,del}'
- ovs-ctl:
* New option '--no-record-hostname' to disable hostname configuration
in ovsdb on startup.
diff --git a/lib/mac-learning.c b/lib/mac-learning.c
index 3d5293d3b..5e53f5a6f 100644
--- a/lib/mac-learning.c
+++ b/lib/mac-learning.c
@@ -35,12 +35,23 @@ COVERAGE_DEFINE(mac_learning_expired);
COVERAGE_DEFINE(mac_learning_evicted);
COVERAGE_DEFINE(mac_learning_moved);
-/* Returns the number of seconds since 'e' (within 'ml') was last learned. */
+/*
+ * This function will return age of mac entry in the fdb. It
+ * will return either one of the following:
+ * 1. Number of seconds since 'e' (within 'ml') was last learned.
+ * 2. If the mac entry is a static entry, it returns
+ * MAC_ENTRY_AGE_STATIC_ENTRY
+ */
int
mac_entry_age(const struct mac_learning *ml, const struct mac_entry *e)
{
-time_t remaining = e->expires - time_now();
-return ml->idle_time - remaining;
+/* For static fdb entries, expires would be MAC_ENTRY_AGE_STATIC_ENTRY */
+if (MAC_ENTRY_AGE_STATIC_
Re: [ovs-dev] [PATCH v6] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Ok Ben, Will do that. Thanks -Vasu *Vasu Dasari* On Mon, Jun 14, 2021 at 11:48 AM Ben Pfaff wrote: > On Fri, Jun 11, 2021 at 10:09:58PM -0400, Vasu Dasari wrote: > > Currently there is an option to add/flush/show ARP/ND neighbor. This > covers L3 > > side. For L2 side, there is only fdb show command. This patch gives an > option > > to add/del an fdb entry via ovs-appctl. > > I didn't really review this patch, but I noticed that there is no > documentation for the new commands. Please add some in > vswitchd/ovs-vswitchd.8.in, near the documentation for the existing fdb > commands. > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] ofp-monitor: Extend Flow Monitoring support for OF 1.0-1.3 with Nicira Extensions
Ok Ben. Is it ok if I take this up as a separate submit.
So after this commit, I propose to add the following changes(listing the
tasks):
1. Support for 1.3 ONF extension for flow monitoring
2. Support for 1.4+ flow monitoring.
Thanks,
-Vasu
*Vasu Dasari*
On Mon, Jun 14, 2021 at 2:31 PM Ben Pfaff wrote:
> There are a number of ONF extensions already:
>
> [bpfaff@sigfpe _build]$ git grep -h -E 'ONFS?T'
> ../include/openvswitch/ofp-msgs.h
> * * ONFT: Open Networking Foundation extension message.
> * * ONFST: Open Networking Foundation multipart message.
> * For NXT or ONFT, the 'subtype' in struct ofp_vendor_header.
> * For NXST or ONFST, the 'subtype' in an appropriate vendor stats
> /* ONFT 1.3 (1911): struct ofp14_role_status, uint8_t[8][]. */
> OFPRAW_ONFT13_ROLE_STATUS,
> /* ONFT 1.3 (2350): struct ofp14_requestforward, uint8_t[8][]. */
> OFPRAW_ONFT13_REQUESTFORWARD,
> /* ONFT 1.3 (2300): struct ofp14_bundle_ctrl_msg, uint8_t[8][]. */
> OFPRAW_ONFT13_BUNDLE_CONTROL,
> /* ONFT 1.3 (2301): struct ofp14_bundle_ctrl_msg, uint8_t[]. */
> OFPRAW_ONFT13_BUNDLE_ADD_MESSAGE,
> OFPTYPE_ROLE_STATUS, /* OFPRAW_ONFT13_ROLE_STATUS.
>* OFPRAW_ONFT13_REQUESTFORWARD.
>* OFPRAW_ONFT13_BUNDLE_CONTROL. */
>* OFPRAW_ONFT13_BUNDLE_ADD_MESSAGE. */
>
> The ONF standardized extension is the one we should use.
>
> On Mon, Jun 14, 2021 at 08:03:04AM -0400, Vasu Dasari wrote:
> > Hi Ben,
> >
> > I see that the flow monitoring is added as an ONF extension. I am looking
> > at ofp-msgs.h, I do not see any ONF_ related extensions added in that
> file.
> > If we were to add ONF flow monitoring support to OVS this will be the
> first
> > one. Let me know if this is a desired one.
> >
> > Or, we could continue with the Nicira extension till 1.3 and then follow
> > with a standardized one from 1.4.
> >
> > Let me know what you think.
> >
> > Thanks
> > -Vasu
> >
> > *Vasu Dasari*
> >
> >
> > On Thu, Jun 10, 2021 at 8:25 PM Ben Pfaff wrote:
> >
> > > On Fri, May 14, 2021 at 04:15:25PM -0400, Vasu Dasari wrote:
> > > > Currently OVS supports flow-monitoring for OpenFlow 1.0 and Nicira
> > > Extenstions.
> > > > Any other OpenFlow versioned messages are not accepted. This checkin
> > > will allow
> > > > OpenFlow1.0-1.3 Flow Monitoring wth Nicira extensions be accepted.
> Also
> > > made
> > > > sure that flow-monitoring updates, flow monitoring pause messages,
> resume
> > > > messages are sent in the same OpenFlow version as that of
> flow-monitor
> > > > request
> > >
> > > Thanks for the patch!
> > >
> > > This change here isn't quite accurate since only OF1.0-OF1.3 are
> > > currently supported:
> > >
> > > @@ -515,13 +517,10 @@ parse_flow_monitor_request__(struct
> > > ofputil_flow_monitor_request *fmr,
> > > }
> > >
> > > if (error) {
> > > return error;
> > > }
> > > -/* Flow Monitor is supported in OpenFlow 1.0 or can be
> > > further reduced
> > > - * to a few 1.0 flavors by a match field. */
> > > -*usable_protocols &= OFPUTIL_P_OF10_ANY;
> > > }
> > > return NULL;
> > > }
> > >
> > > /* Convert 'str_' (as described in the documentation for the
> > > "monitor" command
> > >
> > > Actually, it occurs to me that this shouldn't add support for OF1.3
> > > either, only for OF1.1 and OF1.2, because OF1.3 has a standardized
> > > extension, which you can find here:
> > >
> > >
> https://opennetworking.org/wp-content/uploads/2014/10/openflow-extensions-1.3.x-pack2.zip
> > > in the pdf inside for extension 187. It would be better to implement
> > > that for 1.3 rather than to invent our own.
> > >
> > > Thanks,
> > >
> > > Ben.
> > >
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3] ofp-monitor: Extend Flow Monitoring support for OF 1.0-1.2 with Nicira Extensions
Hi Ben
This patch makse all flow-monitoring tests to be tested against all
versions.
For this to happen I have added debug options to "ovs-ofctl
{add,mod,del}-flows " to print out byte streams. I see that other ovs-ofctl
commands like dump-ports, dump-table-features, etc have options to dump
hex bytes of the response. For example,
$ ovs-ofctl dump-ports br0 -m
OFPST_PORT reply (xid=0x2): 1 ports
port LOCAL: rx pkts=0, bytes=0, drop=?, errs=?, frame=?, over=?, crc=?
tx pkts=0, bytes=0, drop=?, errs=?, coll=?
01 11 00 74 00 00 00 02-00 04 00 00 ff fe 00 00 |...t|
0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ||
.
.
No such option exists for add-flow/del-flows/mod-flows. With this commit
one can see the OF packet sent as part request in bytes form different
levels of verbosity.
With verbosity 5:
$ ovs-ofctl add-flow br0 in_port=1,action=2 -m
01 0e 00 50 00 00 00 06-00 38 20 fe 00 01 00 00 |...P.8 .|
0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ||
0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ||
0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 80 00 ||
0040 ff ff ff ff ff ff 00 00-00 00 00 08 00 02 00 00 ||
With verbosity 6:
$ ovs-ofctl add-flow br0 in_port=1,action=2 -mm
0x10e0056003820fe0001800000080002
The one with verbosity 6 can be used in ofproto tests to inject openflow
packets using a script rather than constructing it manually, like this:
# Gets hex dump of del-flows command, replaces 0x with 0 and modifies
transaction identifier from whatever to 0x12345678
send_buf=$(ovs-ofctl -O $2 del-flows br0 table=0 -mm | sed 's/0x/0/' |
sed -E 's/^(.{8})(.{8})/\112345678/' )
One can send such packet with:
ovs-appctl -t ovs-ofctl ofctl/send $send_buf
It turns out the change is quite simple so included as part of this commit.
I hope this is ok.
Also, in this version I have shrunk OF from 1.0-1.3 to 1.0-1.2. I am not
totally convinced this is appropriate, Please see the discussion in another
thread
<https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383894.html>.
Thanks
-Vasu
*Vasu Dasari*
On Sun, Jun 13, 2021 at 11:49 PM Vasu Dasari wrote:
> Currently OVS supports flow-monitoring for OpenFlow 1.0 and Nicira
> Extenstions.
> Any other OpenFlow versioned messages are not accepted. This checkin will
> allow
> OpenFlow1.0-1.2 Flow Monitoring wth Nicira extensions be accepted. Also
> made
> sure that flow-monitoring updates, flow monitoring pause messages, resume
> messages are sent in the same OpenFlow version as that of flow-monitor
> request.
>
> Description of changes:
>
> 1. Generate ofp-msgs.inc to be able to support 1.0-1.2 Flow Monitoring
> messages.
> include/openvswitch/ofp-msgs.h
>
> 2. Support vconn to accept user specified version and use it for vconn
> flow-monitoring session
> ofproto/ofproto.c
>
> 3. Modify APIs to use protocol as an argument to encode and decode messages
> include/openvswitch/ofp-monitor.h
> lib/ofp-monitor.c
> ofproto/connmgr.c
> ofproto/connmgr.h
> ofproto/ofproto.c
>
> 4. Modified following testcases to be verified across supported OF Versions
> ofproto - flow monitoring
> ofproto - flow monitoring with !own
> ofproto - flow monitoring with out_port
> ofproto - flow monitoring pause and resume
> ofproto - flow monitoring usable protocols
> tests/ofproto.at
>
> 5. Updated NEWS with the support added with this commit
>
> Signed-off-by: Vasu Dasari
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050820.html
> ---
>
> v1:
> - Addressed code review comments from Ben Pfaff:
> 1. Reduced supported versions from OF 1.0+ to 1.0-1.3 as there is flow
> monitoring is supported in OF 1.4+. Need to make changes as part of
> future
> development to add support for OpenFlow 1.4+
> 2. Added announcement of this support to NEWS
> 3. Extended test cases identified in commit to be tested agains all
> supported
> OF versions.
> v2:
> - Fix 0-day robot error in NEWS file
> v3:
> - Addressed code review comments
> - Reduced OF versions supported to (1.0-1.2)
> - Made all flow monitoring tests to be tested against all openflow
> versions
> - Added an option to dump openflow packets in hex for
> add-flow/del-flow/mod-flow.
>The option to dump bytes is available for "dump" commands but not for
> the flow
>management commands. Using this option to be able to generate packets
> dynamically
>during the flow monitoring tests
> ---
> AUTHORS.rst
Re: [ovs-dev] [PATCH v2] ofp-monitor: Extend Flow Monitoring support for OF 1.0-1.3 with Nicira Extensions
Hi Ben,
I see that the flow monitoring is added as an ONF extension. I am looking
at ofp-msgs.h, I do not see any ONF_ related extensions added in that file.
If we were to add ONF flow monitoring support to OVS this will be the first
one. Let me know if this is a desired one.
Or, we could continue with the Nicira extension till 1.3 and then follow
with a standardized one from 1.4.
Let me know what you think.
Thanks
-Vasu
*Vasu Dasari*
On Thu, Jun 10, 2021 at 8:25 PM Ben Pfaff wrote:
> On Fri, May 14, 2021 at 04:15:25PM -0400, Vasu Dasari wrote:
> > Currently OVS supports flow-monitoring for OpenFlow 1.0 and Nicira
> Extenstions.
> > Any other OpenFlow versioned messages are not accepted. This checkin
> will allow
> > OpenFlow1.0-1.3 Flow Monitoring wth Nicira extensions be accepted. Also
> made
> > sure that flow-monitoring updates, flow monitoring pause messages, resume
> > messages are sent in the same OpenFlow version as that of flow-monitor
> > request
>
> Thanks for the patch!
>
> This change here isn't quite accurate since only OF1.0-OF1.3 are
> currently supported:
>
> @@ -515,13 +517,10 @@ parse_flow_monitor_request__(struct
> ofputil_flow_monitor_request *fmr,
> }
>
> if (error) {
> return error;
> }
> -/* Flow Monitor is supported in OpenFlow 1.0 or can be
> further reduced
> - * to a few 1.0 flavors by a match field. */
> -*usable_protocols &= OFPUTIL_P_OF10_ANY;
> }
> return NULL;
> }
>
> /* Convert 'str_' (as described in the documentation for the
> "monitor" command
>
> Actually, it occurs to me that this shouldn't add support for OF1.3
> either, only for OF1.1 and OF1.2, because OF1.3 has a standardized
> extension, which you can find here:
>
> https://opennetworking.org/wp-content/uploads/2014/10/openflow-extensions-1.3.x-pack2.zip
> in the pdf inside for extension 187. It would be better to implement
> that for 1.3 rather than to invent our own.
>
> Thanks,
>
> Ben.
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v3] ofp-monitor: Extend Flow Monitoring support for OF 1.0-1.2 with Nicira Extensions
Currently OVS supports flow-monitoring for OpenFlow 1.0 and Nicira Extenstions.
Any other OpenFlow versioned messages are not accepted. This checkin will allow
OpenFlow1.0-1.2 Flow Monitoring wth Nicira extensions be accepted. Also made
sure that flow-monitoring updates, flow monitoring pause messages, resume
messages are sent in the same OpenFlow version as that of flow-monitor request.
Description of changes:
1. Generate ofp-msgs.inc to be able to support 1.0-1.2 Flow Monitoring messages.
include/openvswitch/ofp-msgs.h
2. Support vconn to accept user specified version and use it for vconn
flow-monitoring session
ofproto/ofproto.c
3. Modify APIs to use protocol as an argument to encode and decode messages
include/openvswitch/ofp-monitor.h
lib/ofp-monitor.c
ofproto/connmgr.c
ofproto/connmgr.h
ofproto/ofproto.c
4. Modified following testcases to be verified across supported OF Versions
ofproto - flow monitoring
ofproto - flow monitoring with !own
ofproto - flow monitoring with out_port
ofproto - flow monitoring pause and resume
ofproto - flow monitoring usable protocols
tests/ofproto.at
5. Updated NEWS with the support added with this commit
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050820.html
---
v1:
- Addressed code review comments from Ben Pfaff:
1. Reduced supported versions from OF 1.0+ to 1.0-1.3 as there is flow
monitoring is supported in OF 1.4+. Need to make changes as part of future
development to add support for OpenFlow 1.4+
2. Added announcement of this support to NEWS
3. Extended test cases identified in commit to be tested agains all supported
OF versions.
v2:
- Fix 0-day robot error in NEWS file
v3:
- Addressed code review comments
- Reduced OF versions supported to (1.0-1.2)
- Made all flow monitoring tests to be tested against all openflow versions
- Added an option to dump openflow packets in hex for
add-flow/del-flow/mod-flow.
The option to dump bytes is available for "dump" commands but not for the
flow
management commands. Using this option to be able to generate packets
dynamically
during the flow monitoring tests
---
AUTHORS.rst | 2 +-
NEWS | 3 +
include/openvswitch/ofp-monitor.h | 9 +-
include/openvswitch/ofp-msgs.h| 4 +-
lib/ofp-monitor.c | 20 ++--
ofproto/connmgr.c | 18 +++-
ofproto/connmgr.h | 3 +-
ofproto/ofproto.c | 13 ++-
tests/ofproto.at | 172 +-
utilities/ovs-ofctl.c | 22 +++-
10 files changed, 160 insertions(+), 106 deletions(-)
diff --git a/AUTHORS.rst b/AUTHORS.rst
index dbc3bde44..53c749da7 100644
--- a/AUTHORS.rst
+++ b/AUTHORS.rst
@@ -405,6 +405,7 @@ Tony van der Peet
tony.vanderp...@alliedtelesis.co.nz
Tonghao Zhang xiangxia.m@gmail.com
Usman Ansari ua1...@gmail.com
Valient Gough vgo...@pobox.com
+Vasu Dasarivdas...@gmail.com
Venkata Anil Kommaddi vkomm...@redhat.com
Vishal Deep Ajmera vishal.deep.ajm...@ericsson.com
Vivien Bernet-Rollande v...@soprive.net
@@ -674,7 +675,6 @@ Tulio Ribeiro tribe...@lasige.di.fc.ul.pt
Tytus Kurek tytus.ku...@pega.com
Valentin Budvalen...@hackaserver.com
Vasiliy Tolstov v.tols...@selfip.ru
-Vasu Dasari vdas...@gmail.com
Vinllen Chencvinl...@gmail.com
Vishal Swarankarvishal.swarn...@gmail.com
Vjekoslav Brajkovic bal...@cs.washington.edu
diff --git a/NEWS b/NEWS
index ebba17b22..09db14511 100644
--- a/NEWS
+++ b/NEWS
@@ -6,6 +6,9 @@ Post-v2.15.0
monitors, etc. More datails in Documentation/topics/record-replay.rst.
- In ovs-vsctl and vtep-ctl, the "find" command now accept new
operators {in} and {not-in}.
+ - OpenFlow:
+ * Extend Flow Monitoring support for OpenFlow 1.0-1.2 with Nicira
+ Extensions
- Userspace datapath:
* Auto load balancing of PMDs now partially supports cross-NUMA polling
cases, e.g if all PMD threads are running on the same NUMA node.
diff --git a/include/openvswitch/ofp-monitor.h
b/include/openvswitch/ofp-monitor.h
index 237cef85e..835efd0f3 100644
--- a/include/openvswitch/ofp-monitor.h
+++ b/include/openvswitch/ofp-monitor.h
@@ -70,7 +70,8 @@ struct ofputil_flow_monitor_request {
int ofputil_decode_flow_monitor_request(struct ofputil_flow_monitor_request *,
struct ofpbuf *msg);
void ofputil_append_flow_monitor_request(
-const struct ofputil_flow_monitor_request *, struct ofpbuf *msg);
+const struct ofputil_flow_monitor_request *, struct ofpbuf *msg,
+enum ofput
Re: [ovs-dev] [PATCH v4] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
You are right, Eelco. Sorry that I missed two of your comments. I am addressing them in Patch v6 <https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383884.html>. Thanks -Vasu *Vasu Dasari* On Fri, Jun 11, 2021 at 10:35 AM Eelco Chaudron wrote: > Hi Vasu, > > Will try to look at it in more details next week, but found two (actually > one is a nit) not being fixed? > > Any reason, see below… > > //Eelco > > On 10 Jun 2021, at 13:09, Vasu Dasari wrote: > > Hi Eelco, > > I addressed your comments and also added a counter to track number of > static entries in the switch. > > Here is the new Patch v5 > <https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383731.html> . > Please take a look. > > Thanks > -Vasu > > *Vasu Dasari* > > On Wed, May 26, 2021 at 4:52 AM Eelco Chaudron > wrote: > > On 25 May 2021, at 20:11, Vasu Dasari wrote: > > Eelco, Thank you for the detailed review. My comments inline and will > > have > > a new pull-request shortly: > > Thanks, take your time. I’m rather busy this week and early next week. > > //Eelco > > *Vasu Dasari* > > On Tue, May 25, 2021 at 10:32 AM Eelco Chaudron > > wrote: > > I did an initial code review. See comments inline below. > > //Eelco > > On 22 May 2021, at 20:12, Vasu Dasari wrote: > > Currently there is an option to add/flush/show ARP/ND neighbor. This > > covers L3 > > side. For L2 side, there is only fdb show command. This patch gives an > > option > > to add/del an fdb entry via ovs-appctl. > > CLI command looks like: > > To add: > ovs-appctl fdb/add > ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05 > > To del: > ovs-appctl fdb/del > ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05 > > Added two new APIs to provide convenient interface to add and delete > > static-macs. > > void xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t > > in_port, > > struct eth_addr dl_src, int vlan); > void xlate_delete_static_mac_entry(const struct ofproto_dpif *, > struct eth_addr dl_src, int vlan); > > 1. Static entry should not age. To indicate that entry being programmed > > is a static entry, > > 'expires' field in 'struct mac_entry' will be set to a > > MAC_ENTRY_AGE_STATIC_ENTRY. A > > check for this value is made while deleting mac entry as part of > > regular > > aging process. > > 2. Another change to of mac-update logic, when a packet with same > > dl_src > > as that of a > > static-mac entry arrives on any port, the logic will not modify the > > expires field. > > 3. While flushing fdb entries, made sure static ones are not evicted. > > Added following tests: > ofproto-dpif - static-mac add/del/flush > ofproto-dpif - static-mac mac moves > > Signed-off-by: Vasu Dasari > Reported-at: > > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html > > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752 > Tested-by: Eelco Chaudron > --- > v1: > - Fixed 0-day robot warnings > v2: > - Fix valgrind error in the modified code in mac_learning_insert() > > where a read is > > is performed on e->expires which is not initialized > v3: > - Addressed code review comments > - Added more documentation > - Fixed mac_entry_age() and is_mac_learning_update_needed() to have > > common > > understanding of return values when mac_entry is a static one. > - Added NEWS item > v4: > - Addressed code review comments > - Static entries will not be purged when fdb/flush is performed. > - Static entries will not be overwritten when packet with same dl_src > > arrives on > > any port of switch > - Provided bit more detail while doing fdb/add, to indicate if > > static-mac is > > overriding already present entry > - Separated test cases for a bit more clarity > --- > NEWS | 2 + > lib/mac-learning.c | 61 + > lib/mac-learning.h | 11 + > ofproto/ofproto-dpif-xlate.c | 28 > ofproto/ofproto-dpif-xlate.h | 5 ++ > ofproto/ofproto-dpif.c | 88 ++-- > tests/ofproto-dpif.at | 84 ++ > 7 files changed, 266 insertions(+), 13 deletions(-) > > diff --git a/NEWS b/NEWS > index 402ce5969..61ab61462 100644 > --- a/NEWS > +++ b/NEWS > @@ -5,6 +5,8 @@ Post-v2.15.0 > - Userspace datapath: > * Auto load balancing of PMDs now partially supports cross-NUMA > > polling > > cases, e.g if all PMD threads are running on the same NUMA > > node. > > + * Added ability to add and delete static mac entries using:
[ovs-dev] [PATCH v6] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Currently there is an option to add/flush/show ARP/ND neighbor. This covers L3
side. For L2 side, there is only fdb show command. This patch gives an option
to add/del an fdb entry via ovs-appctl.
CLI command looks like:
To add:
ovs-appctl fdb/add
ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05
To del:
ovs-appctl fdb/del
ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05
Added two new APIs to provide convenient interface to add and delete
static-macs.
bool xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t in_port,
struct eth_addr dl_src, int vlan);
bool xlate_delete_static_mac_entry(const struct ofproto_dpif *,
struct eth_addr dl_src, int vlan);
1. Static entry should not age. To indicate that entry being programmed is a
static entry,
'expires' field in 'struct mac_entry' will be set to a
MAC_ENTRY_AGE_STATIC_ENTRY. A
check for this value is made while deleting mac entry as part of regular
aging process.
2. Another change to of mac-update logic, when a packet with same dl_src as
that of a
static-mac entry arrives on any port, the logic will not modify the expires
field.
3. While flushing fdb entries, made sure static ones are not evicted.
4. Updated "ovs-appctl fdb/stats-show br0" to display numberof static entries
in switch
Added following tests:
ofproto-dpif - static-mac add/del/flush
ofproto-dpif - static-mac mac moves
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752
Tested-by: Eelco Chaudron
---
v1:
- Fixed 0-day robot warnings
v2:
- Fix valgrind error in the modified code in mac_learning_insert() where a
read is
is performed on e->expires which is not initialized
v3:
- Addressed code review comments
- Added more documentation
- Fixed mac_entry_age() and is_mac_learning_update_needed() to have common
understanding of return values when mac_entry is a static one.
- Added NEWS item
v4:
- Addressed code review comments
- Static entries will not be purged when fdb/flush is performed.
- Static entries will not be overwritten when packet with same dl_src arrives
on
any port of switch
- Provided bit more detail while doing fdb/add, to indicate if static-mac is
overriding already present entry
- Separated test cases for a bit more clarity
v5:
- Addressed code review comments
- Added new total_static counter to count number of static entries.
- Removed mac_entry_set_idle_time()
- Added mac_learning_add_static_entry() and mac_learning_del_static_entry()
- Modified APIs xlate_add_static_mac_entry() and
xlate_delete_static_mac_entry()
return 0 on success else a failure code
v6:
- Fixed a probable bug with Eelco's code review comments in
is_mac_learning_update_needed()
---
NEWS | 2 +
lib/mac-learning.c | 149 +++
lib/mac-learning.h | 17
ofproto/ofproto-dpif-xlate.c | 48 +--
ofproto/ofproto-dpif-xlate.h | 5 ++
ofproto/ofproto-dpif.c | 95 +-
tests/ofproto-dpif.at| 93 ++
7 files changed, 380 insertions(+), 29 deletions(-)
diff --git a/NEWS b/NEWS
index ebba17b22..501b26cee 100644
--- a/NEWS
+++ b/NEWS
@@ -9,6 +9,8 @@ Post-v2.15.0
- Userspace datapath:
* Auto load balancing of PMDs now partially supports cross-NUMA polling
cases, e.g if all PMD threads are running on the same NUMA node.
+ * Added ability to add and delete static mac entries using:
+ 'ovs-appctl fdb/{add,del}'
- ovs-ctl:
* New option '--no-record-hostname' to disable hostname configuration
in ovsdb on startup.
diff --git a/lib/mac-learning.c b/lib/mac-learning.c
index 3d5293d3b..2f51a6553 100644
--- a/lib/mac-learning.c
+++ b/lib/mac-learning.c
@@ -35,12 +35,23 @@ COVERAGE_DEFINE(mac_learning_expired);
COVERAGE_DEFINE(mac_learning_evicted);
COVERAGE_DEFINE(mac_learning_moved);
-/* Returns the number of seconds since 'e' (within 'ml') was last learned. */
+/*
+ * This function will return age of mac entry in the fdb. It
+ * will return either one of the following:
+ * 1. Number of seconds since 'e' (within 'ml') was last learned.
+ * 2. If the mac entry is a static entry, it returns
+ * MAC_ENTRY_AGE_STATIC_ENTRY
+ */
int
mac_entry_age(const struct mac_learning *ml, const struct mac_entry *e)
{
-time_t remaining = e->expires - time_now();
-return ml->idle_time - remaining;
+/* For static fdb entries, expires would be MAC_ENTRY_AGE_STATIC_ENTRY */
+if (MAC_ENTRY_AGE_STATIC_ENTRY == e->expires) {
+return MAC_ENTRY_AGE_STATIC_ENTRY;
+} else {
+time_t remaining = e->expires - time_now();
+return ml->idle_time - remaining;
+}
}
static uint32_t
@@ -187,6 +198,7 @@ mac_lear
Re: [ovs-dev] [PATCH] ofp-monitor: Extend Flow Monitoring support for OF 1.0+ with Nicira Extensions
Thanks Ben. Will try this out.
-Vasu
*Vasu Dasari*
On Thu, Jun 10, 2021 at 5:32 PM Ben Pfaff wrote:
> You can apply a patch like this to get it to log hex:
>
> diff --git a/lib/vconn.c b/lib/vconn.c
> index 7415e6291f6f..c626c35f9792 100644
> --- a/lib/vconn.c
> +++ b/lib/vconn.c
> @@ -685,7 +685,7 @@ do_send(struct vconn *vconn, struct ofpbuf *msg)
> COVERAGE_INC(vconn_sent);
> retval = (vconn->vclass->send)(vconn, msg);
> } else {
> -char *s = ofp_to_string(msg->data, msg->size, NULL, NULL, 1);
> +char *s = ofp_to_string(msg->data, msg->size, NULL, NULL, 5);
> retval = (vconn->vclass->send)(vconn, msg);
> if (retval != EAGAIN) {
> VLOG_DBG_RL(_rl, "%s: sent (%s): %s",
>
>
> On Wed, Jun 09, 2021 at 08:17:18PM -0400, Vasu Dasari wrote:
> > Hi Ben,
> >
> > I know you might be busy. Can you please share how to construct byte
> > stream, I will do it.
> >
> > I looked at ovs-ofctl command debug options to see if there is a way to
> > print out the byte OpenFlow packet's byte stream, I could not find one.
> >
> > Thanks
> > -Vasu
> >
> > *Vasu Dasari*
> >
> >
> > On Fri, May 14, 2021 at 5:09 PM Ben Pfaff wrote:
> >
> > > On Fri, May 14, 2021 at 03:48:53PM -0400, Vasu Dasari wrote:
> > > > Hi Ben,
> > > >
> > > > Quick comment on test case extension. I have added wrappers as you
> > > > suggested that code looks good. But I ran into a version specific
> problem
> > > > for testcase, "ofproto - flow monitoring". It uses is a ofctl/send
> > > > <
> > >
> https://github.com/openvswitch/ovs/blob/7100c220e669443aa646513ce6cb241ccf2caf5c/tests/ofproto.at#L4695
> > > >
> > > > command
> > > > to perform flow-delete operation, which works well for 1.0 as the
> byte
> > > > stream is handcrafted for version 1. But for any other version, we
> need
> > > to
> > > > construct th byte stream and call ofctl/send. So, I left following
> as it
> > > is
> > >
> > > The easiest way to construct the byte stream is probably to run
> > > ovs-ofctl and record what it sends. It shouldn't be very hard to do
> > > that, so I'd just go ahead and do it.
> > >
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Hi Eelco, I addressed your comments and also added a counter to track number of static entries in the switch. Here is the new Patch v5 <https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383731.html>. Please take a look. Thanks -Vasu *Vasu Dasari* On Wed, May 26, 2021 at 4:52 AM Eelco Chaudron wrote: > > > On 25 May 2021, at 20:11, Vasu Dasari wrote: > > > Eelco, Thank you for the detailed review. My comments inline and will > have > > a new pull-request shortly: > > Thanks, take your time. I’m rather busy this week and early next week. > > //Eelco > > > > *Vasu Dasari* > > > > > > On Tue, May 25, 2021 at 10:32 AM Eelco Chaudron > wrote: > > > >> I did an initial code review. See comments inline below. > >> > >> //Eelco > >> > >> > >> On 22 May 2021, at 20:12, Vasu Dasari wrote: > >> > >>> Currently there is an option to add/flush/show ARP/ND neighbor. This > >> covers L3 > >>> side. For L2 side, there is only fdb show command. This patch gives an > >> option > >>> to add/del an fdb entry via ovs-appctl. > >>> > >>> CLI command looks like: > >>> > >>> To add: > >>> ovs-appctl fdb/add > >>> ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05 > >>> > >>> To del: > >>> ovs-appctl fdb/del > >>> ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05 > >>> > >>> Added two new APIs to provide convenient interface to add and delete > >> static-macs. > >>> void xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t > >> in_port, > >>>struct eth_addr dl_src, int vlan); > >>> void xlate_delete_static_mac_entry(const struct ofproto_dpif *, > >>> struct eth_addr dl_src, int vlan); > >>> > >>> 1. Static entry should not age. To indicate that entry being programmed > >> is a static entry, > >>> 'expires' field in 'struct mac_entry' will be set to a > >> MAC_ENTRY_AGE_STATIC_ENTRY. A > >>> check for this value is made while deleting mac entry as part of > regular > >> aging process. > >>> 2. Another change to of mac-update logic, when a packet with same > dl_src > >> as that of a > >>> static-mac entry arrives on any port, the logic will not modify the > >> expires field. > >>> 3. While flushing fdb entries, made sure static ones are not evicted. > >>> > >>> Added following tests: > >>> ofproto-dpif - static-mac add/del/flush > >>> ofproto-dpif - static-mac mac moves > >>> > >>> Signed-off-by: Vasu Dasari > >>> Reported-at: > >> > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html > >>> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752 > >>> Tested-by: Eelco Chaudron > >>> --- > >>> v1: > >>> - Fixed 0-day robot warnings > >>> v2: > >>> - Fix valgrind error in the modified code in mac_learning_insert() > >> where a read is > >>>is performed on e->expires which is not initialized > >>> v3: > >>> - Addressed code review comments > >>> - Added more documentation > >>> - Fixed mac_entry_age() and is_mac_learning_update_needed() to have > >> common > >>>understanding of return values when mac_entry is a static one. > >>> - Added NEWS item > >>> v4: > >>> - Addressed code review comments > >>> - Static entries will not be purged when fdb/flush is performed. > >>> - Static entries will not be overwritten when packet with same dl_src > >> arrives on > >>>any port of switch > >>> - Provided bit more detail while doing fdb/add, to indicate if > >> static-mac is > >>>overriding already present entry > >>> - Separated test cases for a bit more clarity > >>> --- > >>> NEWS | 2 + > >>> lib/mac-learning.c | 61 + > >>> lib/mac-learning.h | 11 + > >>> ofproto/ofproto-dpif-xlate.c | 28 > >>> ofproto/ofproto-dpif-xlate.h | 5 ++ > >>> ofproto/ofproto-dpif.c | 88 ++-- > >>> tests/ofproto-dpif.at| 84 +++
[ovs-dev] [PATCH v5] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Currently there is an option to add/flush/show ARP/ND neighbor. This covers L3
side. For L2 side, there is only fdb show command. This patch gives an option
to add/del an fdb entry via ovs-appctl.
CLI command looks like:
To add:
ovs-appctl fdb/add
ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05
To del:
ovs-appctl fdb/del
ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05
Added two new APIs to provide convenient interface to add and delete
static-macs.
bool xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t in_port,
struct eth_addr dl_src, int vlan);
bool xlate_delete_static_mac_entry(const struct ofproto_dpif *,
struct eth_addr dl_src, int vlan);
1. Static entry should not age. To indicate that entry being programmed is a
static entry,
'expires' field in 'struct mac_entry' will be set to a
MAC_ENTRY_AGE_STATIC_ENTRY. A
check for this value is made while deleting mac entry as part of regular
aging process.
2. Another change to of mac-update logic, when a packet with same dl_src as
that of a
static-mac entry arrives on any port, the logic will not modify the expires
field.
3. While flushing fdb entries, made sure static ones are not evicted.
4. Updated "ovs-appctl fdb/stats-show br0" to display numberof static entries
in switch
Added following tests:
ofproto-dpif - static-mac add/del/flush
ofproto-dpif - static-mac mac moves
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752
Tested-by: Eelco Chaudron
---
v1:
- Fixed 0-day robot warnings
v2:
- Fix valgrind error in the modified code in mac_learning_insert() where a
read is
is performed on e->expires which is not initialized
v3:
- Addressed code review comments
- Added more documentation
- Fixed mac_entry_age() and is_mac_learning_update_needed() to have common
understanding of return values when mac_entry is a static one.
- Added NEWS item
v4:
- Addressed code review comments
- Static entries will not be purged when fdb/flush is performed.
- Static entries will not be overwritten when packet with same dl_src arrives
on
any port of switch
- Provided bit more detail while doing fdb/add, to indicate if static-mac is
overriding already present entry
- Separated test cases for a bit more clarity
v5:
- Addressed code review comments
- Added new total_static counter to count number of static entries.
- Removed mac_entry_set_idle_time()
- Added mac_learning_add_static_entry() and mac_learning_del_static_entry()
- Modified APIs xlate_add_static_mac_entry() and
xlate_delete_static_mac_entry()
return 0 on success else a failure code
---
NEWS | 2 +
lib/mac-learning.c | 141 ++-
lib/mac-learning.h | 17 +
ofproto/ofproto-dpif-xlate.c | 48 ++--
ofproto/ofproto-dpif-xlate.h | 5 ++
ofproto/ofproto-dpif.c | 95 ++-
tests/ofproto-dpif.at| 93 +++
7 files changed, 372 insertions(+), 29 deletions(-)
diff --git a/NEWS b/NEWS
index ebba17b22..501b26cee 100644
--- a/NEWS
+++ b/NEWS
@@ -9,6 +9,8 @@ Post-v2.15.0
- Userspace datapath:
* Auto load balancing of PMDs now partially supports cross-NUMA polling
cases, e.g if all PMD threads are running on the same NUMA node.
+ * Added ability to add and delete static mac entries using:
+ 'ovs-appctl fdb/{add,del}'
- ovs-ctl:
* New option '--no-record-hostname' to disable hostname configuration
in ovsdb on startup.
diff --git a/lib/mac-learning.c b/lib/mac-learning.c
index 3d5293d3b..66cb3eefb 100644
--- a/lib/mac-learning.c
+++ b/lib/mac-learning.c
@@ -35,12 +35,23 @@ COVERAGE_DEFINE(mac_learning_expired);
COVERAGE_DEFINE(mac_learning_evicted);
COVERAGE_DEFINE(mac_learning_moved);
-/* Returns the number of seconds since 'e' (within 'ml') was last learned. */
+/*
+ * This function will return age of mac entry in the fdb. It
+ * will return either one of the following:
+ * 1. Number of seconds since 'e' (within 'ml') was last learned.
+ * 2. If the mac entry is a static entry, it returns
+ * MAC_ENTRY_AGE_STATIC_ENTRY
+ */
int
mac_entry_age(const struct mac_learning *ml, const struct mac_entry *e)
{
-time_t remaining = e->expires - time_now();
-return ml->idle_time - remaining;
+/* For static fdb entries, expires would be MAC_ENTRY_AGE_STATIC_ENTRY */
+if (MAC_ENTRY_AGE_STATIC_ENTRY == e->expires) {
+return e->expires;
+} else {
+time_t remaining = e->expires - time_now();
+return ml->idle_time - remaining;
+}
}
static uint32_t
@@ -187,6 +198,7 @@ mac_learning_clear_statistics(struct mac_learning *ml)
{
if (ml != NULL) {
ml->total_learned
Re: [ovs-dev] [PATCH] ofp-monitor: Extend Flow Monitoring support for OF 1.0+ with Nicira Extensions
Hi Ben, I know you might be busy. Can you please share how to construct byte stream, I will do it. I looked at ovs-ofctl command debug options to see if there is a way to print out the byte OpenFlow packet's byte stream, I could not find one. Thanks -Vasu *Vasu Dasari* On Fri, May 14, 2021 at 5:09 PM Ben Pfaff wrote: > On Fri, May 14, 2021 at 03:48:53PM -0400, Vasu Dasari wrote: > > Hi Ben, > > > > Quick comment on test case extension. I have added wrappers as you > > suggested that code looks good. But I ran into a version specific problem > > for testcase, "ofproto - flow monitoring". It uses is a ofctl/send > > < > https://github.com/openvswitch/ovs/blob/7100c220e669443aa646513ce6cb241ccf2caf5c/tests/ofproto.at#L4695 > > > > command > > to perform flow-delete operation, which works well for 1.0 as the byte > > stream is handcrafted for version 1. But for any other version, we need > to > > construct th byte stream and call ofctl/send. So, I left following as it > is > > The easiest way to construct the byte stream is probably to run > ovs-ofctl and record what it sends. It shouldn't be very hard to do > that, so I'd just go ahead and do it. > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Eelco, Thank you for the detailed review. My comments inline and will have
a new pull-request shortly:
*Vasu Dasari*
On Tue, May 25, 2021 at 10:32 AM Eelco Chaudron wrote:
> I did an initial code review. See comments inline below.
>
> //Eelco
>
>
> On 22 May 2021, at 20:12, Vasu Dasari wrote:
>
> > Currently there is an option to add/flush/show ARP/ND neighbor. This
> covers L3
> > side. For L2 side, there is only fdb show command. This patch gives an
> option
> > to add/del an fdb entry via ovs-appctl.
> >
> > CLI command looks like:
> >
> > To add:
> > ovs-appctl fdb/add
> > ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05
> >
> > To del:
> > ovs-appctl fdb/del
> > ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05
> >
> > Added two new APIs to provide convenient interface to add and delete
> static-macs.
> > void xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t
> in_port,
> >struct eth_addr dl_src, int vlan);
> > void xlate_delete_static_mac_entry(const struct ofproto_dpif *,
> > struct eth_addr dl_src, int vlan);
> >
> > 1. Static entry should not age. To indicate that entry being programmed
> is a static entry,
> > 'expires' field in 'struct mac_entry' will be set to a
> MAC_ENTRY_AGE_STATIC_ENTRY. A
> > check for this value is made while deleting mac entry as part of regular
> aging process.
> > 2. Another change to of mac-update logic, when a packet with same dl_src
> as that of a
> > static-mac entry arrives on any port, the logic will not modify the
> expires field.
> > 3. While flushing fdb entries, made sure static ones are not evicted.
> >
> > Added following tests:
> > ofproto-dpif - static-mac add/del/flush
> > ofproto-dpif - static-mac mac moves
> >
> > Signed-off-by: Vasu Dasari
> > Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html
> > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752
> > Tested-by: Eelco Chaudron
> > ---
> > v1:
> > - Fixed 0-day robot warnings
> > v2:
> > - Fix valgrind error in the modified code in mac_learning_insert()
> where a read is
> >is performed on e->expires which is not initialized
> > v3:
> > - Addressed code review comments
> > - Added more documentation
> > - Fixed mac_entry_age() and is_mac_learning_update_needed() to have
> common
> >understanding of return values when mac_entry is a static one.
> > - Added NEWS item
> > v4:
> > - Addressed code review comments
> > - Static entries will not be purged when fdb/flush is performed.
> > - Static entries will not be overwritten when packet with same dl_src
> arrives on
> >any port of switch
> > - Provided bit more detail while doing fdb/add, to indicate if
> static-mac is
> >overriding already present entry
> > - Separated test cases for a bit more clarity
> > ---
> > NEWS | 2 +
> > lib/mac-learning.c | 61 +
> > lib/mac-learning.h | 11 +
> > ofproto/ofproto-dpif-xlate.c | 28
> > ofproto/ofproto-dpif-xlate.h | 5 ++
> > ofproto/ofproto-dpif.c | 88 ++--
> > tests/ofproto-dpif.at| 84 ++
> > 7 files changed, 266 insertions(+), 13 deletions(-)
> >
> > diff --git a/NEWS b/NEWS
> > index 402ce5969..61ab61462 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -5,6 +5,8 @@ Post-v2.15.0
> > - Userspace datapath:
> > * Auto load balancing of PMDs now partially supports cross-NUMA
> polling
> > cases, e.g if all PMD threads are running on the same NUMA node.
> > + * Added ability to add and delete static mac entries using:
> > + 'ovs-appctl fdb/{add,del}'
> > - ovs-ctl:
> > * New option '--no-record-hostname' to disable hostname
> configuration
> > in ovsdb on startup.
> > diff --git a/lib/mac-learning.c b/lib/mac-learning.c
> > index 3d5293d3b..ab58e2ab6 100644
> > --- a/lib/mac-learning.c
> > +++ b/lib/mac-learning.c
> > @@ -35,12 +35,23 @@ COVERAGE_DEFINE(mac_learning_expired);
> > COVERAGE_DEFINE(mac_learning_evicted);
> > COVERAGE_DEFINE(mac_learning_moved);
> >
> > -/* Returns the number of seconds since 'e' (within 'ml') was last
> learned. */
> > +/*
> > + * This function will return age of mac entry in the fdb.
Re: [ovs-dev] [PATCH v3] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Hi Eelco, I addressed your comments and also there was a bug uncovered with unit tests. Here is the PATCH v4 <http://patchwork.ozlabs.org/project/openvswitch/patch/20210522181211.48976-1-vdas...@gmail.com/> Thanks *Vasu Dasari* On Fri, May 21, 2021 at 4:41 AM Eelco Chaudron wrote: > > > On 20 May 2021, at 19:09, Vasu Dasari wrote: > > > Thank you Eelco for testing the patch. > > > > My responses are inline: > > > Thanks, looking forward for your next revision. Would be good if you can > add a test case for the mac move and flush change. > > //Eelco > > > > *Vasu Dasari* > > > > > > On Thu, May 20, 2021 at 5:20 AM Eelco Chaudron > wrote: > > > >> > >> > >> On 14 May 2021, at 21:33, Vasu Dasari wrote: > >> > >>> Currently there is an option to add/flush/show ARP/ND neighbor. This > >> covers L3 > >>> side. For L2 side, there is only fdb show command. This patch gives an > >> option > >>> to add/del an fdb entry via ovs-appctl. ovs-appctl command looks like > >> this: > >>> > >>> To add: > >>> ovs-appctl fdb/add > >>> ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05 > >>> > >>> To del: > >>> ovs-appctl fdb/del > >>> ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05 > >>> > >>> Static entry should not age. To indicate that entry being programmed is > >> a static entry, > >>> 'expires' field in 'struct mac_entry' will be set to a > >> MAC_ENTRY_AGE_STATIC_ENTRY. A > >>> check for this value is made while deleting mac entry as part of > regular > >> aging process. > >>> Another check as part of mac-update process, when a packet with same > >> source mac as this > >>> entry arrives on the configured port will not modify the expires field > >>> > >>> Added two new APIs to provide convenient interface to add and delete > >> static-macs. > >>> void xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t > >> in_port, > >>>struct eth_addr dl_src, int vlan); > >>> void xlate_delete_static_mac_entry(const struct ofproto_dpif *, > >>> struct eth_addr dl_src, int vlan); > >>> > >>> Signed-off-by: Vasu Dasari > >>> Reported-at: > >> > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html > >>> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752 > >> > >> I did some testing and found the issues below, once fixed, I’ll do a > full > >> code review. > > > > When you do an FDB flush, it also clears the static FDB entries. I think > >> this is wrong, as all hardware vendors I know will retain the static FDB > >> entries. > >> > > > > I took the liberty of having fdb/flush clear static entries as well. I do > > not mind changing the code to delete only dynamic ones. Will take care of > > this. > > > > > >> When you create a static entry for lets say Port A, when a packet with > the > >> same MAC comes from Port B the entry will be updated with Port B. This > >> should not happen for static entries. > >> > >> I agree. I tested this case too. It fails. Will fix it. > > > >> When you add a static MAC entry, the command just returns "OK". Other > >> commands do not return anything on a successful addition. You should > either > >> follow the same behavior or be more verbose (Static FDB successfully > >> added?) on your return. > >> > >> Sure, will make the command return error string only if it fails, > > otherwise will be silent. > > > >> Also, it might be nice to be more verbose when you replace an existing > >> static or dynamic FDB entry, i.e. especially if the physical port is > >> different (mac move case). > >> > >> > > Sure, will add more detailed output. > > > >> Cheers, > >> > >> > >> Eelco > >> > >> > > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v4] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Currently there is an option to add/flush/show ARP/ND neighbor. This covers L3
side. For L2 side, there is only fdb show command. This patch gives an option
to add/del an fdb entry via ovs-appctl.
CLI command looks like:
To add:
ovs-appctl fdb/add
ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05
To del:
ovs-appctl fdb/del
ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05
Added two new APIs to provide convenient interface to add and delete
static-macs.
void xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t in_port,
struct eth_addr dl_src, int vlan);
void xlate_delete_static_mac_entry(const struct ofproto_dpif *,
struct eth_addr dl_src, int vlan);
1. Static entry should not age. To indicate that entry being programmed is a
static entry,
'expires' field in 'struct mac_entry' will be set to a
MAC_ENTRY_AGE_STATIC_ENTRY. A
check for this value is made while deleting mac entry as part of regular aging
process.
2. Another change to of mac-update logic, when a packet with same dl_src as
that of a
static-mac entry arrives on any port, the logic will not modify the expires
field.
3. While flushing fdb entries, made sure static ones are not evicted.
Added following tests:
ofproto-dpif - static-mac add/del/flush
ofproto-dpif - static-mac mac moves
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752
Tested-by: Eelco Chaudron
---
v1:
- Fixed 0-day robot warnings
v2:
- Fix valgrind error in the modified code in mac_learning_insert() where a
read is
is performed on e->expires which is not initialized
v3:
- Addressed code review comments
- Added more documentation
- Fixed mac_entry_age() and is_mac_learning_update_needed() to have common
understanding of return values when mac_entry is a static one.
- Added NEWS item
v4:
- Addressed code review comments
- Static entries will not be purged when fdb/flush is performed.
- Static entries will not be overwritten when packet with same dl_src arrives
on
any port of switch
- Provided bit more detail while doing fdb/add, to indicate if static-mac is
overriding already present entry
- Separated test cases for a bit more clarity
---
NEWS | 2 +
lib/mac-learning.c | 61 +
lib/mac-learning.h | 11 +
ofproto/ofproto-dpif-xlate.c | 28
ofproto/ofproto-dpif-xlate.h | 5 ++
ofproto/ofproto-dpif.c | 88 ++--
tests/ofproto-dpif.at| 84 ++
7 files changed, 266 insertions(+), 13 deletions(-)
diff --git a/NEWS b/NEWS
index 402ce5969..61ab61462 100644
--- a/NEWS
+++ b/NEWS
@@ -5,6 +5,8 @@ Post-v2.15.0
- Userspace datapath:
* Auto load balancing of PMDs now partially supports cross-NUMA polling
cases, e.g if all PMD threads are running on the same NUMA node.
+ * Added ability to add and delete static mac entries using:
+ 'ovs-appctl fdb/{add,del}'
- ovs-ctl:
* New option '--no-record-hostname' to disable hostname configuration
in ovsdb on startup.
diff --git a/lib/mac-learning.c b/lib/mac-learning.c
index 3d5293d3b..ab58e2ab6 100644
--- a/lib/mac-learning.c
+++ b/lib/mac-learning.c
@@ -35,12 +35,23 @@ COVERAGE_DEFINE(mac_learning_expired);
COVERAGE_DEFINE(mac_learning_evicted);
COVERAGE_DEFINE(mac_learning_moved);
-/* Returns the number of seconds since 'e' (within 'ml') was last learned. */
+/*
+ * This function will return age of mac entry in the fdb. It
+ * will return either one of the following:
+ * 1. Number of seconds since 'e' (within 'ml') was last learned.
+ * 2. If the mac entry is a static entry, it returns
+ * MAC_ENTRY_AGE_STATIC_ENTRY
+ */
int
mac_entry_age(const struct mac_learning *ml, const struct mac_entry *e)
{
-time_t remaining = e->expires - time_now();
-return ml->idle_time - remaining;
+/* For static fdb entries, expires would be MAC_ENTRY_AGE_STATIC_ENTRY */
+if (MAC_ENTRY_AGE_STATIC_ENTRY == e->expires) {
+return e->expires;
+} else {
+time_t remaining = e->expires - time_now();
+return ml->idle_time - remaining;
+}
}
static uint32_t
@@ -282,6 +293,18 @@ mac_learning_set_idle_time(struct mac_learning *ml,
unsigned int idle_time)
}
}
+/* Changes the MAC aging timeout of a mac_entry to 'idle_time' seconds. */
+void
+mac_entry_set_idle_time(struct mac_learning *ml, struct eth_addr mac,
+int vlan, unsigned int idle_time)
+{
+struct mac_entry *e;
+e = mac_entry_lookup(ml, mac, vlan);
+if (e) {
+e->expires = idle_time;
+}
+}
+
/* Sets the maximum number of entries in 'ml' to 'max_entries', adjusting it
* to be within a reasonable range. */
void
@@ -336,6 +359,7 @@ ma
Re: [ovs-dev] [PATCH v3] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Thank you Eelco for testing the patch. My responses are inline: *Vasu Dasari* On Thu, May 20, 2021 at 5:20 AM Eelco Chaudron wrote: > > > On 14 May 2021, at 21:33, Vasu Dasari wrote: > > > Currently there is an option to add/flush/show ARP/ND neighbor. This > covers L3 > > side. For L2 side, there is only fdb show command. This patch gives an > option > > to add/del an fdb entry via ovs-appctl. ovs-appctl command looks like > this: > > > > To add: > > ovs-appctl fdb/add > > ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05 > > > > To del: > > ovs-appctl fdb/del > > ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05 > > > > Static entry should not age. To indicate that entry being programmed is > a static entry, > > 'expires' field in 'struct mac_entry' will be set to a > MAC_ENTRY_AGE_STATIC_ENTRY. A > > check for this value is made while deleting mac entry as part of regular > aging process. > > Another check as part of mac-update process, when a packet with same > source mac as this > > entry arrives on the configured port will not modify the expires field > > > > Added two new APIs to provide convenient interface to add and delete > static-macs. > > void xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t > in_port, > >struct eth_addr dl_src, int vlan); > > void xlate_delete_static_mac_entry(const struct ofproto_dpif *, > > struct eth_addr dl_src, int vlan); > > > > Signed-off-by: Vasu Dasari > > Reported-at: > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html > > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752 > > I did some testing and found the issues below, once fixed, I’ll do a full > code review. When you do an FDB flush, it also clears the static FDB entries. I think > this is wrong, as all hardware vendors I know will retain the static FDB > entries. > I took the liberty of having fdb/flush clear static entries as well. I do not mind changing the code to delete only dynamic ones. Will take care of this. > When you create a static entry for lets say Port A, when a packet with the > same MAC comes from Port B the entry will be updated with Port B. This > should not happen for static entries. > > I agree. I tested this case too. It fails. Will fix it. > When you add a static MAC entry, the command just returns "OK". Other > commands do not return anything on a successful addition. You should either > follow the same behavior or be more verbose (Static FDB successfully > added?) on your return. > > Sure, will make the command return error string only if it fails, otherwise will be silent. > Also, it might be nice to be more verbose when you replace an existing > static or dynamic FDB entry, i.e. especially if the physical port is > different (mac move case). > > Sure, will add more detailed output. > Cheers, > > > Eelco > > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofp-monitor: Extend Flow Monitoring support for OF 1.0+ with Nicira Extensions
Ok Thank you. > On May 14, 2021, at 5:09 PM, Ben Pfaff wrote: > > On Fri, May 14, 2021 at 03:48:53PM -0400, Vasu Dasari wrote: >> Hi Ben, >> >> Quick comment on test case extension. I have added wrappers as you >> suggested that code looks good. But I ran into a version specific problem >> for testcase, "ofproto - flow monitoring". It uses is a ofctl/send >> <https://github.com/openvswitch/ovs/blob/7100c220e669443aa646513ce6cb241ccf2caf5c/tests/ofproto.at#L4695> >> command >> to perform flow-delete operation, which works well for 1.0 as the byte >> stream is handcrafted for version 1. But for any other version, we need to >> construct th byte stream and call ofctl/send. So, I left following as it is > > The easiest way to construct the byte stream is probably to run > ovs-ofctl and record what it sends. It shouldn't be very hard to do > that, so I'd just go ahead and do it. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2] ofp-monitor: Extend Flow Monitoring support for OF 1.0-1.3 with Nicira Extensions
Currently OVS supports flow-monitoring for OpenFlow 1.0 and Nicira Extenstions.
Any other OpenFlow versioned messages are not accepted. This checkin will allow
OpenFlow1.0-1.3 Flow Monitoring wth Nicira extensions be accepted. Also made
sure that flow-monitoring updates, flow monitoring pause messages, resume
messages are sent in the same OpenFlow version as that of flow-monitor request.
Description of changes:
1. Generate ofp-msgs.inc to be able to support 1.0+ Flow Monitoring messages.
include/openvswitch/ofp-msgs.h
2. Support vconn to accept user specified version and use it for vconn
flow-monitoring session
ofproto/ofproto.c
3. Modify APIs to use protocol as an argument to encode and decode messages
include/openvswitch/ofp-monitor.h
lib/ofp-monitor.c
ofproto/connmgr.c
ofproto/connmgr.h
ofproto/ofproto.c
4. Modified following testcases to be verified across supported OF Versions
ofproto - flow monitoring with out_port
ofproto - flow monitoring pause and resume
ofproto - flow monitoring usable protocols
tests/ofproto.at
5. Updated NEWS with the support added with this commit
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050820.html
---
v1:
Addressed code review comments from Ben Pfaff:
1. Reduced supported versions from OF 1.0+ to 1.0-1.3 as there is flow
monitoring is supported in OF 1.4+. Need to make changes as part of future
development to add support for OpenFlow 1.4+
2. Added announcement of this support to NEWS
3. Extended test cases identified in commit to be tested agains all supported
OF versions.
v2:
Fix 0-day robot error in NEWS file
---
AUTHORS.rst | 2 +-
NEWS | 3 ++
include/openvswitch/ofp-monitor.h | 9 ++--
include/openvswitch/ofp-msgs.h| 4 +-
lib/ofp-monitor.c | 20 +
ofproto/connmgr.c | 18 +---
ofproto/connmgr.h | 3 +-
ofproto/ofproto.c | 13 +++---
tests/ofproto.at | 73 +++
utilities/ovs-ofctl.c | 5 ++-
10 files changed, 93 insertions(+), 57 deletions(-)
diff --git a/AUTHORS.rst b/AUTHORS.rst
index 60e4ffbe6..f212ce1c7 100644
--- a/AUTHORS.rst
+++ b/AUTHORS.rst
@@ -405,6 +405,7 @@ Tony van der Peet
tony.vanderp...@alliedtelesis.co.nz
Tonghao Zhang xiangxia.m@gmail.com
Usman Ansari ua1...@gmail.com
Valient Gough vgo...@pobox.com
+Vasu Dasarivdas...@gmail.com
Venkata Anil Kommaddi vkomm...@redhat.com
Vishal Deep Ajmera vishal.deep.ajm...@ericsson.com
Vivien Bernet-Rollande v...@soprive.net
@@ -673,7 +674,6 @@ Tulio Ribeiro tribe...@lasige.di.fc.ul.pt
Tytus Kurek tytus.ku...@pega.com
Valentin Budvalen...@hackaserver.com
Vasiliy Tolstov v.tols...@selfip.ru
-Vasu Dasari vdas...@gmail.com
Vinllen Chencvinl...@gmail.com
Vishal Swarankarvishal.swarn...@gmail.com
Vjekoslav Brajkovic bal...@cs.washington.edu
diff --git a/NEWS b/NEWS
index 402ce5969..157807420 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,9 @@ Post-v2.15.0
-
- In ovs-vsctl and vtep-ctl, the "find" command now accept new
operators {in} and {not-in}.
+ - OpenFlow:
+ * Extend Flow Monitoring support for OpenFlow 1.0-1.3 with Nicira
+ Extensions
- Userspace datapath:
* Auto load balancing of PMDs now partially supports cross-NUMA polling
cases, e.g if all PMD threads are running on the same NUMA node.
diff --git a/include/openvswitch/ofp-monitor.h
b/include/openvswitch/ofp-monitor.h
index 237cef85e..835efd0f3 100644
--- a/include/openvswitch/ofp-monitor.h
+++ b/include/openvswitch/ofp-monitor.h
@@ -70,7 +70,8 @@ struct ofputil_flow_monitor_request {
int ofputil_decode_flow_monitor_request(struct ofputil_flow_monitor_request *,
struct ofpbuf *msg);
void ofputil_append_flow_monitor_request(
-const struct ofputil_flow_monitor_request *, struct ofpbuf *msg);
+const struct ofputil_flow_monitor_request *, struct ofpbuf *msg,
+enum ofputil_protocol protocol);
void ofputil_flow_monitor_request_format(
struct ds *, const struct ofputil_flow_monitor_request *,
const struct ofputil_port_map *, const struct ofputil_table_map *);
@@ -103,7 +104,8 @@ struct ofputil_flow_update {
int ofputil_decode_flow_update(struct ofputil_flow_update *,
struct ofpbuf *msg, struct ofpbuf *ofpacts);
-void ofputil_start_flow_update(struct ovs_list *replies);
+void ofputil_start_flow_update(struct ovs_list *replies,
+ enum ofputil_protocol protoc
Re: [ovs-dev] [PATCH v2] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Hi Ben,
I have addressed code review comments and I think made better documentation
at the new patch, v3.
Patch v3
<http://patchwork.ozlabs.org/project/openvswitch/patch/20210514193309.80837-1-vdas...@gmail.com/>
.
Thanks
-Vasu
*Vasu Dasari*
On Mon, May 10, 2021 at 8:20 PM Vasu Dasari wrote:
> Yes. You are right, Ben. I can have mac_entry_age() return 0, in case of
> static entry. Actually, this following code is preventing age from getting
> overwritten.
>
> void@@ -336,6 +353,7 @@ mac_learning_insert(struct mac_learning *ml,
> e->vlan = vlan;
> e->grat_arp_lock = TIME_MIN;
> e->mlport = NULL;+e->expires = 0;
> COVERAGE_INC(mac_learning_learned);
> ml->total_learned++;
> } else {@@ -348,7 +366,10 @@ mac_learning_insert(struct mac_learning
> *ml,
> ovs_list_remove(>port_lru_node);
> ovs_list_push_back(>mlport->port_lrus, >port_lru_node);
> }-e->expires = time_now() + ml->idle_time;+/* Do not update
> 'expires' for static mac entry */+if (e->expires != INT_MAX) {+
> e->expires = time_now() + ml->idle_time;+}
>
>
> I will modify the code in mac_entry_age() to return 0, that would prevent
> extra processing.
>
> Thanks
>
> *Vasu Dasari*
>
>
> On Mon, May 10, 2021 at 7:55 PM Ben Pfaff wrote:
>
>> I do not see how that helps. mac_entry_age() returns -1 if the entry is
>> static, and its caller uses mac_entry_age() like this:
>>
>> if (!mac || mac_entry_age(ml, mac)) {
>> return true;
>> }
>>
>> which means that -1 will cause learning to happen.
>>
>> On Mon, May 10, 2021 at 07:43:46PM -0400, Vasu Dasari wrote:
>> > 2. In mac_entry_age(), added new code to protect the age of the static
>> > entry being overwritten by a received packet.
>> >
>> > int
>> > mac_entry_age(const struct mac_learning *ml, const struct mac_entry *e)
>> > {-time_t remaining = e->expires - time_now();-return
>> > ml->idle_time - remaining;+/* For static fdb entries, expires
>> > would be initialized with INT_MAX */+ if (INT_MAX == e->expires) {+
>> >return -1;+} else {+time_t remaining = e->expires -
>> > time_now();+return ml->idle_time - remaining;+}
>> > }
>> >
>> >
>> > Hope this answers your question.
>> >
>> > Thanks
>> > -Vasu
>> >
>> > *Vasu Dasari*
>> >
>> >
>> > On Mon, May 10, 2021 at 2:57 PM Ben Pfaff wrote:
>> >
>> > > On Sat, May 08, 2021 at 06:18:41PM -0400, Vasu Dasari wrote:
>> > > > Currently there is an option to add/flush/show ARP/ND neighbor. This
>> > > covers L3
>> > > > side. For L2 side, there is only fdb show command. This patch
>> gives an
>> > > option
>> > > > to add/del an fdb entry via CLI.
>> > > >
>> > > > CLI command looks like:
>> > > >
>> > > > To add:
>> > > > ovs-appctl fdb/add
>> > > > ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05
>> > > >
>> > > > To del:
>> > > > ovs-appctl fdb/del
>> > > > ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05
>> > > >
>> > > > Static entry should not age. To indicate that entry being
>> programmed is
>> > > a static entry,
>> > > > 'expires' field in 'struct mac_entry' will be set to a INT_MAX. A
>> check
>> > > for this value
>> > > > is made while deleting mac entry as part of regular aging process.
>> > > Another check as part
>> > > > of mac-update process, when a packet with same source mac as this
>> entry
>> > > arrives on the
>> > > > configured port will not modify the expires field
>> > > >
>> > > > Added two new APIs to provide convinient interfacde to add and
>> delete
>> > > static-macs
>> > > > void xlate_add_static_mac_entry(const struct ofproto_dpif *,
>> ofp_port_t
>> > > in_port,
>> > > >struct eth_addr dl_src, int vlan);
>> > > > void xlate_delete_static_mac_entry(const struct ofproto_dpif *,
>> > > > struct eth_addr dl_src, int vlan);
>> > > >
>> > > > Signed-off-by: Vasu Dasari
>> > > > Reported-at:
>> > >
>> https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html
>> > > > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752
>> > >
>> > > Needs documentation.
>> > >
>> > > I would expect a static entry to be one that couldn't be changed by
>> > > receiving a packet that causes MAC learning, but I don't see anything
>> > > that protects from that in here.
>> > >
>>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofp-monitor: Extend Flow Monitoring support for OF 1.0+ with Nicira Extensions
Hi Ben, Quick comment on test case extension. I have added wrappers as you suggested that code looks good. But I ran into a version specific problem for testcase, "ofproto - flow monitoring". It uses is a ofctl/send <https://github.com/openvswitch/ovs/blob/7100c220e669443aa646513ce6cb241ccf2caf5c/tests/ofproto.at#L4695> command to perform flow-delete operation, which works well for 1.0 as the byte stream is handcrafted for version 1. But for any other version, we need to construct th byte stream and call ofctl/send. So, I left following as it is 4579:AT_SETUP([ofproto - flow monitoring]) 4716:AT_SETUP([ofproto - flow monitoring with !own]) but enhanced these cases to handle all supported versions. 4757:AT_SETUP([ofproto - flow monitoring with out_port]) 4809:AT_SETUP([ofproto - flow monitoring pause and resume]) Here is the latest latest patch <http://patchwork.ozlabs.org/project/openvswitch/patch/20210514193917.81656-1-vdas...@gmail.com/>. Pardon me, I forgot to add v1 to the subject line but I have added the v1 changes in the patch. Thanks -Vasu *Vasu Dasari* On Mon, May 10, 2021 at 8:22 PM Vasu Dasari wrote: > Ok. Thanks Ben. Will take care of this. > > -Vasu > > *Vasu Dasari* > > > On Mon, May 10, 2021 at 7:57 PM Ben Pfaff wrote: > >> On Mon, May 10, 2021 at 07:38:08PM -0400, Vasu Dasari wrote: >> > 1. Adding Nicira extensions for Flow Monitoring was pretty >> straightforward >> > with the existing code base. As you might have seen, I just had to tweak >> > some functions to get this to work. I do not have any hard opinions >> against >> > your point that we should not duplicate functionality with Nicira >> > extensions and OpenFlow 1.4,1.5. But my only suggestion is to make the >> > support for OF 1.4, 1.5 flow monitoring messages to be implemented as a >> > separate commit, as I think it is going to add new functions to make >> that >> > happen. >> >> I agree. For this commit, though, I think that it should only add >> support up to 1.3, that is, ofp-msgs.h should say 1.0-1.3, not 1.0+. >> >> Thanks, >> >> Ben. >> > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] ofp-monitor: Extend Flow Monitoring support for OF 1.0-1.3 with Nicira Extensions
Currently OVS supports flow-monitoring for OpenFlow 1.0 and Nicira Extenstions.
Any other OpenFlow versioned messages are not accepted. This checkin will allow
OpenFlow1.0-1.3 Flow Monitoring wth Nicira extensions be accepted. Also made
sure that flow-monitoring updates, flow monitoring pause messages, resume
messages are sent in the same OpenFlow version as that of flow-monitor request.
Description of changes:
1. Generate ofp-msgs.inc to be able to support 1.0+ Flow Monitoring messages.
include/openvswitch/ofp-msgs.h
2. Support vconn to accept user specified version and use it for vconn
flow-monitoring session
ofproto/ofproto.c
3. Modify APIs to use protocol as an argument to encode and decode messages
include/openvswitch/ofp-monitor.h
lib/ofp-monitor.c
ofproto/connmgr.c
ofproto/connmgr.h
ofproto/ofproto.c
4. Modified following testcases to be verified across supported OF Versions
ofproto - flow monitoring with out_port
ofproto - flow monitoring pause and resume
ofproto - flow monitoring usable protocols
tests/ofproto.at
5. Updated NEWS with the support added with this commit
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050820.html
---
v1:
Addressed code review comments from Ben Pfaff:
1. Reduced supported versions from OF 1.0+ to 1.0-1.3 as there is flow
monitoring is supported in OF 1.4+. Need to make changes as part of future
development to add support for OpenFlow 1.4+
2. Added announcement of this support to NEWS
3. Extended test cases identified in commit to be tested agains all supported
OF versions.
---
AUTHORS.rst | 2 +-
NEWS | 2 +
include/openvswitch/ofp-monitor.h | 9 ++--
include/openvswitch/ofp-msgs.h| 4 +-
lib/ofp-monitor.c | 20 +
ofproto/connmgr.c | 18 +---
ofproto/connmgr.h | 3 +-
ofproto/ofproto.c | 13 +++---
tests/ofproto.at | 73 +++
utilities/ovs-ofctl.c | 5 ++-
10 files changed, 92 insertions(+), 57 deletions(-)
diff --git a/AUTHORS.rst b/AUTHORS.rst
index 60e4ffbe6..f212ce1c7 100644
--- a/AUTHORS.rst
+++ b/AUTHORS.rst
@@ -405,6 +405,7 @@ Tony van der Peet
tony.vanderp...@alliedtelesis.co.nz
Tonghao Zhang xiangxia.m@gmail.com
Usman Ansari ua1...@gmail.com
Valient Gough vgo...@pobox.com
+Vasu Dasarivdas...@gmail.com
Venkata Anil Kommaddi vkomm...@redhat.com
Vishal Deep Ajmera vishal.deep.ajm...@ericsson.com
Vivien Bernet-Rollande v...@soprive.net
@@ -673,7 +674,6 @@ Tulio Ribeiro tribe...@lasige.di.fc.ul.pt
Tytus Kurek tytus.ku...@pega.com
Valentin Budvalen...@hackaserver.com
Vasiliy Tolstov v.tols...@selfip.ru
-Vasu Dasari vdas...@gmail.com
Vinllen Chencvinl...@gmail.com
Vishal Swarankarvishal.swarn...@gmail.com
Vjekoslav Brajkovic bal...@cs.washington.edu
diff --git a/NEWS b/NEWS
index 402ce5969..307133b62 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,8 @@ Post-v2.15.0
-
- In ovs-vsctl and vtep-ctl, the "find" command now accept new
operators {in} and {not-in}.
+ - OpenFlow:
+ * Extend Flow Monitoring support for OpenFlow 1.0-1.3 with Nicira
Extensions
- Userspace datapath:
* Auto load balancing of PMDs now partially supports cross-NUMA polling
cases, e.g if all PMD threads are running on the same NUMA node.
diff --git a/include/openvswitch/ofp-monitor.h
b/include/openvswitch/ofp-monitor.h
index 237cef85e..835efd0f3 100644
--- a/include/openvswitch/ofp-monitor.h
+++ b/include/openvswitch/ofp-monitor.h
@@ -70,7 +70,8 @@ struct ofputil_flow_monitor_request {
int ofputil_decode_flow_monitor_request(struct ofputil_flow_monitor_request *,
struct ofpbuf *msg);
void ofputil_append_flow_monitor_request(
-const struct ofputil_flow_monitor_request *, struct ofpbuf *msg);
+const struct ofputil_flow_monitor_request *, struct ofpbuf *msg,
+enum ofputil_protocol protocol);
void ofputil_flow_monitor_request_format(
struct ds *, const struct ofputil_flow_monitor_request *,
const struct ofputil_port_map *, const struct ofputil_table_map *);
@@ -103,7 +104,8 @@ struct ofputil_flow_update {
int ofputil_decode_flow_update(struct ofputil_flow_update *,
struct ofpbuf *msg, struct ofpbuf *ofpacts);
-void ofputil_start_flow_update(struct ovs_list *replies);
+void ofputil_start_flow_update(struct ovs_list *replies,
+ enum ofputil_protocol protocol);
void ofputil_append_flow_update(const struct ofputil_f
[ovs-dev] [PATCH v3] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Currently there is an option to add/flush/show ARP/ND neighbor. This covers L3
side. For L2 side, there is only fdb show command. This patch gives an option
to add/del an fdb entry via ovs-appctl. ovs-appctl command looks like this:
To add:
ovs-appctl fdb/add
ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05
To del:
ovs-appctl fdb/del
ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05
Static entry should not age. To indicate that entry being programmed is a
static entry,
'expires' field in 'struct mac_entry' will be set to a
MAC_ENTRY_AGE_STATIC_ENTRY. A
check for this value is made while deleting mac entry as part of regular aging
process.
Another check as part of mac-update process, when a packet with same source mac
as this
entry arrives on the configured port will not modify the expires field
Added two new APIs to provide convenient interface to add and delete
static-macs.
void xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t in_port,
struct eth_addr dl_src, int vlan);
void xlate_delete_static_mac_entry(const struct ofproto_dpif *,
struct eth_addr dl_src, int vlan);
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752
---
v1:
- Fixed 0-day robot warnings
v2:
- Fix valgrind error in the modified code in mac_learning_insert() where a
read is
is performed on e->expires which is not initialized
v3:
- Addressed code review comments
- Added more documentation
- Fixed mac_entry_age() and is_mac_learning_update_needed() to have common
understanding of return values when mac_entry is a static one.
- Added NEWS item
---
NEWS | 2 ++
lib/mac-learning.c | 38 ---
lib/mac-learning.h | 11 +++
ofproto/ofproto-dpif-xlate.c | 26
ofproto/ofproto-dpif-xlate.h | 5 +++
ofproto/ofproto-dpif.c | 60 +---
tests/ofproto-dpif.at| 55 +
7 files changed, 188 insertions(+), 9 deletions(-)
diff --git a/NEWS b/NEWS
index 402ce5969..61ab61462 100644
--- a/NEWS
+++ b/NEWS
@@ -5,6 +5,8 @@ Post-v2.15.0
- Userspace datapath:
* Auto load balancing of PMDs now partially supports cross-NUMA polling
cases, e.g if all PMD threads are running on the same NUMA node.
+ * Added ability to add and delete static mac entries using:
+ 'ovs-appctl fdb/{add,del}'
- ovs-ctl:
* New option '--no-record-hostname' to disable hostname configuration
in ovsdb on startup.
diff --git a/lib/mac-learning.c b/lib/mac-learning.c
index 3d5293d3b..f7c6ef538 100644
--- a/lib/mac-learning.c
+++ b/lib/mac-learning.c
@@ -35,12 +35,23 @@ COVERAGE_DEFINE(mac_learning_expired);
COVERAGE_DEFINE(mac_learning_evicted);
COVERAGE_DEFINE(mac_learning_moved);
-/* Returns the number of seconds since 'e' (within 'ml') was last learned. */
+/*
+ * This function will return age of mac entry in the fdb. It
+ * will return either one of the following:
+ * 1. Number of seconds since 'e' (within 'ml') was last learned.
+ * 2. If the mac entry is a static entry, it returns
+ * MAC_ENTRY_AGE_STATIC_ENTRY
+ */
int
mac_entry_age(const struct mac_learning *ml, const struct mac_entry *e)
{
-time_t remaining = e->expires - time_now();
-return ml->idle_time - remaining;
+/* For static fdb entries, expires would be MAC_ENTRY_AGE_STATIC_ENTRY */
+if (MAC_ENTRY_AGE_STATIC_ENTRY == e->expires) {
+return e->expires;
+} else {
+time_t remaining = e->expires - time_now();
+return ml->idle_time - remaining;
+}
}
static uint32_t
@@ -282,6 +293,18 @@ mac_learning_set_idle_time(struct mac_learning *ml,
unsigned int idle_time)
}
}
+/* Changes the MAC aging timeout of a mac_entry to 'idle_time' seconds. */
+void
+mac_entry_set_idle_time(struct mac_learning *ml, struct eth_addr mac,
+int vlan, unsigned int idle_time)
+{
+struct mac_entry *e;
+e = mac_entry_lookup(ml, mac, vlan);
+if (e) {
+e->expires = idle_time;
+}
+}
+
/* Sets the maximum number of entries in 'ml' to 'max_entries', adjusting it
* to be within a reasonable range. */
void
@@ -336,6 +359,7 @@ mac_learning_insert(struct mac_learning *ml,
e->vlan = vlan;
e->grat_arp_lock = TIME_MIN;
e->mlport = NULL;
+e->expires = 0;
COVERAGE_INC(mac_learning_learned);
ml->total_learned++;
} else {
@@ -348,7 +372,10 @@ mac_learning_insert(struct mac_learning *ml,
ovs_list_remove(>port_lru_node);
ovs_list_push_back(>mlport->port_lrus, >port_lru_node);
}
-e->expires = time_now() + ml->idle_time;
+/* Do not update 'expires' for static mac entry */
+i
Re: [ovs-dev] [PATCH] ofp-monitor: Extend Flow Monitoring support for OF 1.0+ with Nicira Extensions
Ok. Thanks Ben. Will take care of this. -Vasu *Vasu Dasari* On Mon, May 10, 2021 at 7:57 PM Ben Pfaff wrote: > On Mon, May 10, 2021 at 07:38:08PM -0400, Vasu Dasari wrote: > > 1. Adding Nicira extensions for Flow Monitoring was pretty > straightforward > > with the existing code base. As you might have seen, I just had to tweak > > some functions to get this to work. I do not have any hard opinions > against > > your point that we should not duplicate functionality with Nicira > > extensions and OpenFlow 1.4,1.5. But my only suggestion is to make the > > support for OF 1.4, 1.5 flow monitoring messages to be implemented as a > > separate commit, as I think it is going to add new functions to make that > > happen. > > I agree. For this commit, though, I think that it should only add > support up to 1.3, that is, ofp-msgs.h should say 1.0-1.3, not 1.0+. > > Thanks, > > Ben. > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Yes. You are right, Ben. I can have mac_entry_age() return 0, in case of
static entry. Actually, this following code is preventing age from getting
overwritten.
void@@ -336,6 +353,7 @@ mac_learning_insert(struct mac_learning *ml,
e->vlan = vlan;
e->grat_arp_lock = TIME_MIN;
e->mlport = NULL;+e->expires = 0;
COVERAGE_INC(mac_learning_learned);
ml->total_learned++;
} else {@@ -348,7 +366,10 @@ mac_learning_insert(struct mac_learning *ml,
ovs_list_remove(>port_lru_node);
ovs_list_push_back(>mlport->port_lrus, >port_lru_node);
}-e->expires = time_now() + ml->idle_time;+/* Do not
update 'expires' for static mac entry */+if (e->expires !=
INT_MAX) {+e->expires = time_now() + ml->idle_time;+}
I will modify the code in mac_entry_age() to return 0, that would prevent
extra processing.
Thanks
*Vasu Dasari*
On Mon, May 10, 2021 at 7:55 PM Ben Pfaff wrote:
> I do not see how that helps. mac_entry_age() returns -1 if the entry is
> static, and its caller uses mac_entry_age() like this:
>
> if (!mac || mac_entry_age(ml, mac)) {
> return true;
> }
>
> which means that -1 will cause learning to happen.
>
> On Mon, May 10, 2021 at 07:43:46PM -0400, Vasu Dasari wrote:
> > 2. In mac_entry_age(), added new code to protect the age of the static
> > entry being overwritten by a received packet.
> >
> > int
> > mac_entry_age(const struct mac_learning *ml, const struct mac_entry *e)
> > {-time_t remaining = e->expires - time_now();-return
> > ml->idle_time - remaining;+/* For static fdb entries, expires
> > would be initialized with INT_MAX */+if (INT_MAX == e->expires) {+
> >return -1;+} else {+time_t remaining = e->expires -
> > time_now();+ return ml->idle_time - remaining;+}
> > }
> >
> >
> > Hope this answers your question.
> >
> > Thanks
> > -Vasu
> >
> > *Vasu Dasari*
> >
> >
> > On Mon, May 10, 2021 at 2:57 PM Ben Pfaff wrote:
> >
> > > On Sat, May 08, 2021 at 06:18:41PM -0400, Vasu Dasari wrote:
> > > > Currently there is an option to add/flush/show ARP/ND neighbor. This
> > > covers L3
> > > > side. For L2 side, there is only fdb show command. This patch gives
> an
> > > option
> > > > to add/del an fdb entry via CLI.
> > > >
> > > > CLI command looks like:
> > > >
> > > > To add:
> > > > ovs-appctl fdb/add
> > > > ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05
> > > >
> > > > To del:
> > > > ovs-appctl fdb/del
> > > > ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05
> > > >
> > > > Static entry should not age. To indicate that entry being programmed
> is
> > > a static entry,
> > > > 'expires' field in 'struct mac_entry' will be set to a INT_MAX. A
> check
> > > for this value
> > > > is made while deleting mac entry as part of regular aging process.
> > > Another check as part
> > > > of mac-update process, when a packet with same source mac as this
> entry
> > > arrives on the
> > > > configured port will not modify the expires field
> > > >
> > > > Added two new APIs to provide convinient interfacde to add and delete
> > > static-macs
> > > > void xlate_add_static_mac_entry(const struct ofproto_dpif *,
> ofp_port_t
> > > in_port,
> > > >struct eth_addr dl_src, int vlan);
> > > > void xlate_delete_static_mac_entry(const struct ofproto_dpif *,
> > > > struct eth_addr dl_src, int vlan);
> > > >
> > > > Signed-off-by: Vasu Dasari
> > > > Reported-at:
> > >
> https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html
> > > > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752
> > >
> > > Needs documentation.
> > >
> > > I would expect a static entry to be one that couldn't be changed by
> > > receiving a packet that causes MAC learning, but I don't see anything
> > > that protects from that in here.
> > >
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
1. Sure. Will add more documentation to the code.
2. In mac_entry_age(), added new code to protect the age of the static
entry being overwritten by a received packet.
int
mac_entry_age(const struct mac_learning *ml, const struct mac_entry *e)
{-time_t remaining = e->expires - time_now();-return
ml->idle_time - remaining;+/* For static fdb entries, expires
would be initialized with INT_MAX */+if (INT_MAX == e->expires) {+
return -1;+} else {+time_t remaining = e->expires -
time_now();+return ml->idle_time - remaining;+}
}
Hope this answers your question.
Thanks
-Vasu
*Vasu Dasari*
On Mon, May 10, 2021 at 2:57 PM Ben Pfaff wrote:
> On Sat, May 08, 2021 at 06:18:41PM -0400, Vasu Dasari wrote:
> > Currently there is an option to add/flush/show ARP/ND neighbor. This
> covers L3
> > side. For L2 side, there is only fdb show command. This patch gives an
> option
> > to add/del an fdb entry via CLI.
> >
> > CLI command looks like:
> >
> > To add:
> > ovs-appctl fdb/add
> > ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05
> >
> > To del:
> > ovs-appctl fdb/del
> > ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05
> >
> > Static entry should not age. To indicate that entry being programmed is
> a static entry,
> > 'expires' field in 'struct mac_entry' will be set to a INT_MAX. A check
> for this value
> > is made while deleting mac entry as part of regular aging process.
> Another check as part
> > of mac-update process, when a packet with same source mac as this entry
> arrives on the
> > configured port will not modify the expires field
> >
> > Added two new APIs to provide convinient interfacde to add and delete
> static-macs
> > void xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t
> in_port,
> >struct eth_addr dl_src, int vlan);
> > void xlate_delete_static_mac_entry(const struct ofproto_dpif *,
> > struct eth_addr dl_src, int vlan);
> >
> > Signed-off-by: Vasu Dasari
> > Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html
> > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752
>
> Needs documentation.
>
> I would expect a static entry to be one that couldn't be changed by
> receiving a packet that causes MAC learning, but I don't see anything
> that protects from that in here.
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofp-monitor: Extend Flow Monitoring support for OF 1.0+ with Nicira Extensions
Thanks Ben for your comments. 1. Adding Nicira extensions for Flow Monitoring was pretty straightforward with the existing code base. As you might have seen, I just had to tweak some functions to get this to work. I do not have any hard opinions against your point that we should not duplicate functionality with Nicira extensions and OpenFlow 1.4,1.5. But my only suggestion is to make the support for OF 1.4, 1.5 flow monitoring messages to be implemented as a separate commit, as I think it is going to add new functions to make that happen. 2. Sure, I will add this support announcement to NEWS. 3. I saw the test cases you identified and I like your idea of writing a wrapper function to test those test cases across all possible versions. My take is, if one test case is written thoroughly to cover all versions with some basic test, that should suffice testing core functionality as it is the same across all versions. That is why I have extended "ofproto - flow monitoring usable protocols" to test other protocols. I will look into your suggestion. Thanks -Vasu *Vasu Dasari* On Mon, May 10, 2021 at 3:27 PM Ben Pfaff wrote: > On Sat, May 08, 2021 at 07:12:27AM -0400, Vasu Dasari wrote: > > Currently OVS supports flow-monitoring for OpenFlow 1.0 and Nicira > Extenstions. > > Any other OpenFlow versioned messages are not accepted. This checkin > will allow > > OpenFlow1.0+ Flow Monitoring wth Nicira extensions be accepted. Also > made sure > > that flow-monitoring updates, flow monitoring pause messages, resume > messages > > are sent in the same OpenFlow version as that of flow-monitor request. > > > > Description of changes: > > > > 1. Generate ofp-msgs.inc to be able to support 1.0+ Flow Monitoring > messages. > > include/openvswitch/ofp-msgs.h > > > > 2. Support vconn to accept user specified version and use it for vconn > flow-monitoring session > > ofproto/ofproto.c > > > > 3. Modify APIs to use protocol as an argument to encode and decode > messages > > include/openvswitch/ofp-monitor.h > > include/openvswitch/vlog.h > > lib/ofp-monitor.c > > ofproto/connmgr.c > > ofproto/connmgr.h > > ofproto/ofproto.c > > > > 4. Testcase for verification > > tests/ofproto.at > > > > Signed-off-by: Vasu Dasari > > Reported-at: > https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050820.html > > Signed-off-by: Vasu Dasari > > Thanks for working on this. > > OpenFlow 1.1-1.3 don't have flow monitoring support built into the > protocol, so it makes sense to support it as an extension. This commit > adds the entension for 1.4 and 1.5 as well. I am not convinced that > makes sense, since OF1.4+ has its own support. It's not great to > duplicate functionality if we can avoid it. > > This should add an item in NEWS. I think an update to documentation for > ovs-ofctl might be warranted too, although I didn't look. > > The update to the tests here just check that the extension appears > available. There are multiple other flow monitoring tests: > >4579:AT_SETUP([ofproto - flow monitoring]) >4716:AT_SETUP([ofproto - flow monitoring with !own]) >4757:AT_SETUP([ofproto - flow monitoring with out_port]) >4809:AT_SETUP([ofproto - flow monitoring pause and resume]) > > It would be good to run at least some of these tests with those other > versions as well. They are fairly big, so cutting and pasting wouldn't > be ideal; perhaps some m4 macro work or shell function work would be > better. > > Thanks, > > Ben. > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Currently there is an option to add/flush/show ARP/ND neighbor. This covers L3
side. For L2 side, there is only fdb show command. This patch gives an option
to add/del an fdb entry via CLI.
CLI command looks like:
To add:
ovs-appctl fdb/add
ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05
To del:
ovs-appctl fdb/del
ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05
Static entry should not age. To indicate that entry being programmed is a
static entry,
'expires' field in 'struct mac_entry' will be set to a INT_MAX. A check for
this value
is made while deleting mac entry as part of regular aging process. Another
check as part
of mac-update process, when a packet with same source mac as this entry arrives
on the
configured port will not modify the expires field
Added two new APIs to provide convinient interfacde to add and delete
static-macs
void xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t in_port,
struct eth_addr dl_src, int vlan);
void xlate_delete_static_mac_entry(const struct ofproto_dpif *,
struct eth_addr dl_src, int vlan);
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752
---
v1:
- Fixed 0-day robot warnings
v2:
- Fix valgrind error in the modified code in mac_learning_insert() where a
read is
is performed on e->expires which is not initialized
---
lib/mac-learning.c | 27 ++---
lib/mac-learning.h | 3 +++
ofproto/ofproto-dpif-xlate.c | 26
ofproto/ofproto-dpif-xlate.h | 5
ofproto/ofproto-dpif.c | 47
tests/ofproto-dpif.at| 40 ++
6 files changed, 145 insertions(+), 3 deletions(-)
diff --git a/lib/mac-learning.c b/lib/mac-learning.c
index 9442858d9..437db894c 100644
--- a/lib/mac-learning.c
+++ b/lib/mac-learning.c
@@ -39,8 +39,13 @@ COVERAGE_DEFINE(mac_learning_moved);
int
mac_entry_age(const struct mac_learning *ml, const struct mac_entry *e)
{
-time_t remaining = e->expires - time_now();
-return ml->idle_time - remaining;
+/* For static fdb entries, expires would be initialized with INT_MAX */
+if (INT_MAX == e->expires) {
+return -1;
+} else {
+time_t remaining = e->expires - time_now();
+return ml->idle_time - remaining;
+}
}
static uint32_t
@@ -282,6 +287,18 @@ mac_learning_set_idle_time(struct mac_learning *ml,
unsigned int idle_time)
}
}
+/* Changes the MAC aging timeout of a mac_entry to 'idle_time' seconds. */
+void
+mac_entry_set_idle_time(struct mac_learning *ml, struct eth_addr mac,
+int vlan, unsigned int idle_time)
+{
+struct mac_entry *e;
+e = mac_entry_lookup(ml, mac, vlan);
+if (e) {
+e->expires = idle_time;
+}
+}
+
/* Sets the maximum number of entries in 'ml' to 'max_entries', adjusting it
* to be within a reasonable range. */
void
@@ -336,6 +353,7 @@ mac_learning_insert(struct mac_learning *ml,
e->vlan = vlan;
e->grat_arp_lock = TIME_MIN;
e->mlport = NULL;
+e->expires = 0;
COVERAGE_INC(mac_learning_learned);
ml->total_learned++;
} else {
@@ -348,7 +366,10 @@ mac_learning_insert(struct mac_learning *ml,
ovs_list_remove(>port_lru_node);
ovs_list_push_back(>mlport->port_lrus, >port_lru_node);
}
-e->expires = time_now() + ml->idle_time;
+/* Do not update 'expires' for static mac entry */
+if (e->expires != INT_MAX) {
+e->expires = time_now() + ml->idle_time;
+}
return e;
}
diff --git a/lib/mac-learning.h b/lib/mac-learning.h
index 0ddab06cb..1137aae63 100644
--- a/lib/mac-learning.h
+++ b/lib/mac-learning.h
@@ -202,6 +202,9 @@ bool mac_learning_set_flood_vlans(struct mac_learning *ml,
void mac_learning_set_idle_time(struct mac_learning *ml,
unsigned int idle_time)
OVS_REQ_WRLOCK(ml->rwlock);
+void mac_entry_set_idle_time(struct mac_learning *ml, struct eth_addr src,
+ int vlan, unsigned int idle_time)
+OVS_REQ_WRLOCK(ml->rwlock);
void mac_learning_set_max_entries(struct mac_learning *ml, size_t max_entries)
OVS_REQ_WRLOCK(ml->rwlock);
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 7108c8a30..8580b39f4 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -8011,6 +8011,32 @@ xlate_mac_learning_update(const struct ofproto_dpif
*ofproto,
update_learning_table__(xbridge, xbundle, dl_src, vlan, is_grat_arp);
}
+void
+xlate_add_static_mac_entry(const struct ofproto_dpif *ofproto,
+ ofp_port_t in_port,
+ struct eth_addr dl_s
[ovs-dev] [PATCH] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Currently there is an option to add/flush/show ARP/ND neighbor. This covers L3
side. For L2 side, there is only fdb show command. This patch gives an option
to add/del an fdb entry via CLI.
CLI command looks like:
To add:
ovs-appctl fdb/add
ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05
To del:
ovs-appctl fdb/del
ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05
Static entry should not age. To indicate that entry being programmed is a
static entry,
'expires' field in 'struct mac_entry' will be set to a INT_MAX. A check for
this value
is made while deleting mac entry as part of regular aging process. Another
check as part
of mac-update process, when a packet with same source mac as this entry arrives
on the
configured port will not modify the expires field
Added two new APIs to provide convinient interfacde to add and delete
static-macs
void xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t in_port,
struct eth_addr dl_src, int vlan);
void xlate_delete_static_mac_entry(const struct ofproto_dpif *,
struct eth_addr dl_src, int vlan);
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752
---
v1:
- Fixed 0-day robot warnings
---
lib/mac-learning.c | 26 +---
lib/mac-learning.h | 3 +++
ofproto/ofproto-dpif-xlate.c | 26
ofproto/ofproto-dpif-xlate.h | 5
ofproto/ofproto-dpif.c | 47
tests/ofproto-dpif.at| 40 ++
6 files changed, 144 insertions(+), 3 deletions(-)
diff --git a/lib/mac-learning.c b/lib/mac-learning.c
index 9442858d9..ff21289e8 100644
--- a/lib/mac-learning.c
+++ b/lib/mac-learning.c
@@ -39,8 +39,13 @@ COVERAGE_DEFINE(mac_learning_moved);
int
mac_entry_age(const struct mac_learning *ml, const struct mac_entry *e)
{
-time_t remaining = e->expires - time_now();
-return ml->idle_time - remaining;
+/* For static fdb entries, expires would be initialized with INT_MAX */
+if (INT_MAX == e->expires) {
+return -1;
+} else {
+time_t remaining = e->expires - time_now();
+return ml->idle_time - remaining;
+}
}
static uint32_t
@@ -282,6 +287,18 @@ mac_learning_set_idle_time(struct mac_learning *ml,
unsigned int idle_time)
}
}
+/* Changes the MAC aging timeout of a mac_entry to 'idle_time' seconds. */
+void
+mac_entry_set_idle_time(struct mac_learning *ml, struct eth_addr mac,
+int vlan, unsigned int idle_time)
+{
+struct mac_entry *e;
+e = mac_entry_lookup(ml, mac, vlan);
+if (e) {
+e->expires = idle_time;
+}
+}
+
/* Sets the maximum number of entries in 'ml' to 'max_entries', adjusting it
* to be within a reasonable range. */
void
@@ -348,7 +365,10 @@ mac_learning_insert(struct mac_learning *ml,
ovs_list_remove(>port_lru_node);
ovs_list_push_back(>mlport->port_lrus, >port_lru_node);
}
-e->expires = time_now() + ml->idle_time;
+/* Do not update 'expires' for static mac entry */
+if (e->expires != INT_MAX) {
+e->expires = time_now() + ml->idle_time;
+}
return e;
}
diff --git a/lib/mac-learning.h b/lib/mac-learning.h
index 0ddab06cb..1137aae63 100644
--- a/lib/mac-learning.h
+++ b/lib/mac-learning.h
@@ -202,6 +202,9 @@ bool mac_learning_set_flood_vlans(struct mac_learning *ml,
void mac_learning_set_idle_time(struct mac_learning *ml,
unsigned int idle_time)
OVS_REQ_WRLOCK(ml->rwlock);
+void mac_entry_set_idle_time(struct mac_learning *ml, struct eth_addr src,
+ int vlan, unsigned int idle_time)
+OVS_REQ_WRLOCK(ml->rwlock);
void mac_learning_set_max_entries(struct mac_learning *ml, size_t max_entries)
OVS_REQ_WRLOCK(ml->rwlock);
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 7108c8a30..8580b39f4 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -8011,6 +8011,32 @@ xlate_mac_learning_update(const struct ofproto_dpif
*ofproto,
update_learning_table__(xbridge, xbundle, dl_src, vlan, is_grat_arp);
}
+void
+xlate_add_static_mac_entry(const struct ofproto_dpif *ofproto,
+ ofp_port_t in_port,
+ struct eth_addr dl_src, int vlan)
+{
+xlate_mac_learning_update(ofproto, in_port, dl_src, vlan, false);
+
+ovs_rwlock_wrlock(>ml->rwlock);
+mac_entry_set_idle_time(ofproto->ml, dl_src, vlan, INT_MAX);
+ovs_rwlock_unlock(>ml->rwlock);
+}
+
+void
+xlate_delete_static_mac_entry(const struct ofproto_dpif *ofproto,
+ struct eth_addr dl_src, int vlan)
+{
+struct mac_entry *e = NULL;
+
+ovs
[ovs-dev] [PATCH] ofproto-dpif: APIs and CLI option to add/delete static fdb entry
Currently there is an option to add/flush/show ARP/ND neighbor. This covers L3
side. For L2 side, there is only fdb show command. This patch gives an option
to add/del an fdb entry via CLI.
CLI command looks like:
To add:
ovs-appctl fdb/add
ovs-appctl fdb/add br0 p1 0 50:54:00:00:00:05
To del:
ovs-appctl fdb/del
ovs-appctl fdb/del br0 p1 0 50:54:00:00:00:05
Static entry should not age. To indicate that entry being programmed is a
static entry,
'expires' field in 'struct mac_entry' will be set to a INT_MAX. A check for
this value
is made while deleting mac entry as part of regular aging process. Another
check as part
of mac-update process, when a packet with same source mac as this entry arrives
on the
configured port will not modify the expires field
Added two new APIs to provide convinient interfacde to add and delete
static-macs
void xlate_add_static_mac_entry(const struct ofproto_dpif *, ofp_port_t in_port,
struct eth_addr dl_src, int vlan);
void xlate_delete_static_mac_entry(const struct ofproto_dpif *,
struct eth_addr dl_src, int vlan);
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048894.html
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1597752
---
lib/mac-learning.c | 26 +---
lib/mac-learning.h | 3 +++
ofproto/ofproto-dpif-xlate.c | 25
ofproto/ofproto-dpif-xlate.h | 4
ofproto/ofproto-dpif.c | 46
tests/ofproto-dpif.at| 40 +++
6 files changed, 141 insertions(+), 3 deletions(-)
diff --git a/lib/mac-learning.c b/lib/mac-learning.c
index 9442858d9..ff21289e8 100644
--- a/lib/mac-learning.c
+++ b/lib/mac-learning.c
@@ -39,8 +39,13 @@ COVERAGE_DEFINE(mac_learning_moved);
int
mac_entry_age(const struct mac_learning *ml, const struct mac_entry *e)
{
-time_t remaining = e->expires - time_now();
-return ml->idle_time - remaining;
+/* For static fdb entries, expires would be initialized with INT_MAX */
+if (INT_MAX == e->expires) {
+return -1;
+} else {
+time_t remaining = e->expires - time_now();
+return ml->idle_time - remaining;
+}
}
static uint32_t
@@ -282,6 +287,18 @@ mac_learning_set_idle_time(struct mac_learning *ml,
unsigned int idle_time)
}
}
+/* Changes the MAC aging timeout of a mac_entry to 'idle_time' seconds. */
+void
+mac_entry_set_idle_time(struct mac_learning *ml, struct eth_addr mac,
+int vlan, unsigned int idle_time)
+{
+struct mac_entry *e;
+e = mac_entry_lookup(ml, mac, vlan);
+if (e) {
+e->expires = idle_time;
+}
+}
+
/* Sets the maximum number of entries in 'ml' to 'max_entries', adjusting it
* to be within a reasonable range. */
void
@@ -348,7 +365,10 @@ mac_learning_insert(struct mac_learning *ml,
ovs_list_remove(>port_lru_node);
ovs_list_push_back(>mlport->port_lrus, >port_lru_node);
}
-e->expires = time_now() + ml->idle_time;
+/* Do not update 'expires' for static mac entry */
+if (e->expires != INT_MAX) {
+e->expires = time_now() + ml->idle_time;
+}
return e;
}
diff --git a/lib/mac-learning.h b/lib/mac-learning.h
index 0ddab06cb..1137aae63 100644
--- a/lib/mac-learning.h
+++ b/lib/mac-learning.h
@@ -202,6 +202,9 @@ bool mac_learning_set_flood_vlans(struct mac_learning *ml,
void mac_learning_set_idle_time(struct mac_learning *ml,
unsigned int idle_time)
OVS_REQ_WRLOCK(ml->rwlock);
+void mac_entry_set_idle_time(struct mac_learning *ml, struct eth_addr src,
+ int vlan, unsigned int idle_time)
+OVS_REQ_WRLOCK(ml->rwlock);
void mac_learning_set_max_entries(struct mac_learning *ml, size_t max_entries)
OVS_REQ_WRLOCK(ml->rwlock);
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 7108c8a30..f1072234e 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -8011,6 +8011,31 @@ xlate_mac_learning_update(const struct ofproto_dpif
*ofproto,
update_learning_table__(xbridge, xbundle, dl_src, vlan, is_grat_arp);
}
+void
+xlate_add_static_mac_entry(const struct ofproto_dpif *ofproto, ofp_port_t
in_port,
+ struct eth_addr dl_src, int vlan)
+{
+xlate_mac_learning_update(ofproto, in_port, dl_src, vlan, false);
+
+ovs_rwlock_wrlock(>ml->rwlock);
+mac_entry_set_idle_time(ofproto->ml, dl_src, vlan, INT_MAX);
+ovs_rwlock_unlock(>ml->rwlock);
+}
+
+void
+xlate_delete_static_mac_entry(const struct ofproto_dpif *ofproto,
+ struct eth_addr dl_src, int vlan)
+{
+struct mac_entry *e = NULL;
+
+ovs_rwlock_wrlock(>ml->rwlock);
+e = mac_learning_lo
[ovs-dev] [PATCH] ofp-monitor: Extend Flow Monitoring support for OF 1.0+ with Nicira Extensions
Currently OVS supports flow-monitoring for OpenFlow 1.0 and Nicira Extenstions.
Any other OpenFlow versioned messages are not accepted. This checkin will allow
OpenFlow1.0+ Flow Monitoring wth Nicira extensions be accepted. Also made sure
that flow-monitoring updates, flow monitoring pause messages, resume messages
are sent in the same OpenFlow version as that of flow-monitor request.
Description of changes:
1. Generate ofp-msgs.inc to be able to support 1.0+ Flow Monitoring messages.
include/openvswitch/ofp-msgs.h
2. Support vconn to accept user specified version and use it for vconn
flow-monitoring session
ofproto/ofproto.c
3. Modify APIs to use protocol as an argument to encode and decode messages
include/openvswitch/ofp-monitor.h
include/openvswitch/vlog.h
lib/ofp-monitor.c
ofproto/connmgr.c
ofproto/connmgr.h
ofproto/ofproto.c
4. Testcase for verification
tests/ofproto.at
Signed-off-by: Vasu Dasari
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050820.html
Signed-off-by: Vasu Dasari
---
include/openvswitch/ofp-monitor.h | 9 ++---
include/openvswitch/ofp-msgs.h| 4 ++--
lib/ofp-monitor.c | 20 +++-
ofproto/connmgr.c | 18 +-
ofproto/connmgr.h | 3 ++-
ofproto/ofproto.c | 13 -
tests/ofproto.at | 21 +++--
utilities/ovs-ofctl.c | 5 +++--
8 files changed, 60 insertions(+), 33 deletions(-)
diff --git a/include/openvswitch/ofp-monitor.h
b/include/openvswitch/ofp-monitor.h
index 237cef85e..835efd0f3 100644
--- a/include/openvswitch/ofp-monitor.h
+++ b/include/openvswitch/ofp-monitor.h
@@ -70,7 +70,8 @@ struct ofputil_flow_monitor_request {
int ofputil_decode_flow_monitor_request(struct ofputil_flow_monitor_request *,
struct ofpbuf *msg);
void ofputil_append_flow_monitor_request(
-const struct ofputil_flow_monitor_request *, struct ofpbuf *msg);
+const struct ofputil_flow_monitor_request *, struct ofpbuf *msg,
+enum ofputil_protocol protocol);
void ofputil_flow_monitor_request_format(
struct ds *, const struct ofputil_flow_monitor_request *,
const struct ofputil_port_map *, const struct ofputil_table_map *);
@@ -103,7 +104,8 @@ struct ofputil_flow_update {
int ofputil_decode_flow_update(struct ofputil_flow_update *,
struct ofpbuf *msg, struct ofpbuf *ofpacts);
-void ofputil_start_flow_update(struct ovs_list *replies);
+void ofputil_start_flow_update(struct ovs_list *replies,
+ enum ofputil_protocol protocol);
void ofputil_append_flow_update(const struct ofputil_flow_update *,
struct ovs_list *replies,
const struct tun_table *);
@@ -114,7 +116,8 @@ void ofputil_flow_update_format(struct ds *,
/* Abstract nx_flow_monitor_cancel. */
uint32_t ofputil_decode_flow_monitor_cancel(const struct ofp_header *);
-struct ofpbuf *ofputil_encode_flow_monitor_cancel(uint32_t id);
+struct ofpbuf *ofputil_encode_flow_monitor_cancel(
+uint32_t id, enum ofputil_protocol protocol);
struct ofputil_requestforward {
ovs_be32 xid;
diff --git a/include/openvswitch/ofp-msgs.h b/include/openvswitch/ofp-msgs.h
index 8457bc7d0..be1bc2745 100644
--- a/include/openvswitch/ofp-msgs.h
+++ b/include/openvswitch/ofp-msgs.h
@@ -453,12 +453,12 @@ enum ofpraw {
/* OFPST 1.4+ (16): uint8_t[8][]. */
OFPRAW_OFPST14_FLOW_MONITOR_REQUEST,
-/* NXST 1.0 (2): uint8_t[8][]. */
+/* NXST 1.0+ (2): uint8_t[8][]. */
OFPRAW_NXST_FLOW_MONITOR_REQUEST,
/* OFPST 1.4+ (16): uint8_t[8][]. */
OFPRAW_OFPST14_FLOW_MONITOR_REPLY,
-/* NXST 1.0 (2): uint8_t[8][]. */
+/* NXST 1.0+ (2): uint8_t[8][]. */
OFPRAW_NXST_FLOW_MONITOR_REPLY,
/* Nicira extension messages.
diff --git a/lib/ofp-monitor.c b/lib/ofp-monitor.c
index e12fa6d2b..51f01b100 100644
--- a/lib/ofp-monitor.c
+++ b/lib/ofp-monitor.c
@@ -386,14 +386,16 @@ ofputil_decode_flow_monitor_request(struct
ofputil_flow_monitor_request *rq,
void
ofputil_append_flow_monitor_request(
-const struct ofputil_flow_monitor_request *rq, struct ofpbuf *msg)
+const struct ofputil_flow_monitor_request *rq, struct ofpbuf *msg,
+enum ofputil_protocol protocol)
{
struct nx_flow_monitor_request *nfmr;
size_t start_ofs;
int match_len;
+enum ofp_version version = ofputil_protocol_to_ofp_version(protocol);
if (!msg->size) {
-ofpraw_put(OFPRAW_NXST_FLOW_MONITOR_REQUEST, OFP10_VERSION, msg);
+ofpraw_put(OFPRAW_NXST_FLOW_MONITOR_REQUEST, version, msg);
}
start_ofs = msg->size;
@@ -517,9 +519,6 @@ parse_flow_monitor_request__(struct
ofputil_flow_monitor_request *fmr,
if (error) {
return error;
}
-/* Flow Monitor is supported in OpenFlow 1.0 or can be f
Re: [ovs-dev] Does the OVS command line support on-root users?
You should be able to use ovs-vsctl commands as non-root users on a vswitch started as a non-root user. For example you can look at how any of the unit test cases are executed in ovs/tests/ofproto.at. For example, you can run one of the test cases as, $ cd $ovs_src_dir $ make check TESTSUITEFLAGS='-k "ofproto - echo request"' *Vasu Dasari* On Mon, Feb 22, 2021 at 3:49 AM wangyunjian wrote: > Hi all: > I have a question to consult: I see that OVS daemon has > been supported to run as non-root in 2015 with the patch > "lib/daemon: support --user option for all OVS daemon", > I would like to know whether the openvswitch command line > such as ovs-vsctl/ovs-appctl will be called as non-root > in any plan, and is there any consideration for calling > as root at present? > > Thanks > ___ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVS Userspace: Usecase with multiple vxlan tunnels
Thanks William. Does your statement mean, by network design, vxlan tunnel ports and underlay bridge ports should not be part of a single bridge domain? -Vasu *Vasu Dasari* On Wed, May 6, 2020 at 3:44 PM William Tu wrote: > On Sun, May 03, 2020 at 11:12:04PM -0400, Vasu Dasari wrote: > > Hi, > > > > I am trying a userspace vxlan test case scenario as follows. ap0, fp0, > ap1 > > and fp1 are namespaces where in packets from ap0 are sent to fp0 over > vxlan > > tunnel and packets from ap1 to fp1 are sent over second vxlan tunnel. And > > br0 for the bridge is handling ARP, route, etc. Note that br0 has two > > addresses on assigned to it. > > > > On executing the script with following command: > > sudo make -s -C _build-gcc/ check-system-userspace TESTSUITEFLAGS='-k > > "modified ping over vxlan tunnel"' > > > > I see that OVS times out and leaving behind br0 and ovs-netdev > interfaces. > > But, if I comment out the one of the addresses on br0 at least the script > > will be successful but the ping on second tunnel will not be successful. > > > > My question is: > > 1. Is this use case supported in userspace OVS mode? > > 2. Am I missing something in configuration? > > > > Thanks > > -Vasu > > > > > > +--+ > >+---+ | | +---+ > >|ap0+--+ +--+fp0| > >+---+ | | +---+ > > | ovs | > >+---+ | br0 | +---+ > >|ap1+--+ +--+fp1| > >+---+ | | +---+ > > +--+ > > > > > > > > We usually have an underlay bridage and overlay bridge. > And the vxlan device is attached to the overlay, and the > underlay bridge has the outer ip assigned. > William > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVS Userspace: Usecase with multiple vxlan tunnels
Hi, I made some changes to the script above to make the use case work. I have put access ports and fabric ports to on different bridges by separating them into br0 and br-underlay. And this configuration works. So my question is, do access ports and fabric ports have to be on separate bridges(by design)? Why can't they be in single bridge as in my earlier script? -Vasu OVS_TRAFFIC_VSWITCHD_START() ADD_BR([br-underlay]) ADD_NAMESPACES(at_fp0, at_fp1, at_ap0, at_ap1) dnl Set up underlay link from host into the namespace using veth pair. ADD_VETH(fp0, at_fp0, br-underlay, "172.31.1.1/24", "00:00:00:00:01:02") ADD_VETH(fp1, at_fp1, br-underlay, "172.31.2.1/24", "00:00:00:00:02:02") ADD_VETH(ap0, at_ap0, br0, "10.1.1.100/24", "00:00:00:00:01:03") ADD_VETH(ap1, at_ap1, br0, "10.1.2.100/24", "00:00:00:00:02:03") AT_CHECK([ovs-vsctl set bridge br-underlay other-config:hwaddr="00:00:00:00:00:01"]) AT_CHECK([ip addr add dev br-underlay "172.31.1.100/24"]) AT_CHECK([ip addr add dev br-underlay "172.31.2.100/24"]) AT_CHECK([ip link set dev br-underlay up]) AT_CHECK([ip link set dev br0 up]) ADD_NATIVE_TUNNEL([vxlan], [at_vxlan_fp0], [at_fp0], [172.31.1.100], [ 10.1.1.1/24], [id 0 dstport 4789]) ADD_NATIVE_TUNNEL([vxlan], [at_vxlan_fp1], [at_fp1], [172.31.2.100], [ 10.1.2.1/24], [id 0 dstport 4789]) AT_CHECK([ovs-vsctl add-port br0 at_vxlan_fp0 -- \ set int at_vxlan_fp0 type=vxlan options:remote_ip=172.31.1.1]) AT_CHECK([ovs-vsctl add-port br0 at_vxlan_fp1 -- \ set int at_vxlan_fp1 type=vxlan options:remote_ip=172.31.2.1]) AT_CHECK([ovs-ofctl add-flow br0 "actions=normal"]) AT_CHECK([ovs-ofctl add-flow br-underlay "actions=normal"]) NS_CHECK_EXEC([at_fp0], [ping -q -c 3 -i 0.3 -w 2 172.31.1.100| FORMAT_PING], [0], [dnl 3 packets transmitted, 3 received, 0% packet loss, time 0ms ]) NS_CHECK_EXEC([at_fp1], [ping -q -c 3 -i 0.3 -w 2 172.31.2.100| FORMAT_PING], [0], [dnl 3 packets transmitted, 3 received, 0% packet loss, time 0ms ]) NS_CHECK_EXEC([at_fp0], [ping -q -c 3 -i 0.3 -w 2 10.1.1.100 | FORMAT_PING], [0], [dnl 3 packets transmitted, 3 received, 0% packet loss, time 0ms ]) NS_CHECK_EXEC([at_fp1], [ping -q -c 3 -i 0.3 -w 2 10.1.2.100 | FORMAT_PING], [0], [dnl 3 packets transmitted, 3 received, 0% packet loss, time 0ms ]) OVS_TRAFFIC_VSWITCHD_STOP AT_CLEANUP *Vasu Dasari* On Sun, May 3, 2020 at 11:12 PM Vasu Dasari wrote: > Hi, > > I am trying a userspace vxlan test case scenario as follows. ap0, fp0, ap1 > and fp1 are namespaces where in packets from ap0 are sent to fp0 over vxlan > tunnel and packets from ap1 to fp1 are sent over second vxlan tunnel. And > br0 for the bridge is handling ARP, route, etc. Note that br0 has two > addresses on assigned to it. > > On executing the script with following command: > sudo make -s -C _build-gcc/ check-system-userspace TESTSUITEFLAGS='-k > "modified ping over vxlan tunnel"' > > I see that OVS times out and leaving behind br0 and ovs-netdev interfaces. > But, if I comment out the one of the addresses on br0 at least the script > will be successful but the ping on second tunnel will not be successful. > > My question is: > 1. Is this use case supported in userspace OVS mode? > 2. Am I missing something in configuration? > > Thanks > -Vasu > > > +--+ >+---+ | | +---+ >|ap0+--+ +--+fp0| >+---+ | | +---+ > | ovs | >+---+ | br0 | +---+ >|ap1+--+ +--+fp1| >+---+ | | +---+ > +--+ > > > > > == > AT_SETUP([datapath - modified ping over vxlan tunnel]) > OVS_CHECK_VXLAN() > > OVS_TRAFFIC_VSWITCHD_START() > > ADD_NAMESPACES(at_fp0, at_fp1, at_ap0, at_ap1) > > dnl Set up underlay link from host into the namespace using veth pair. > ADD_VETH(fp0, at_fp0, br0, "172.31.1.1/24", "00:00:00:00:01:02") > ADD_VETH(ap0, at_ap0, br0, "10.1.1.100/24", "00:00:00:00:01:03") > ADD_VETH(fp1, at_fp1, br0, "172.31.2.1/24", "00:00:00:00:02:02") > ADD_VETH(ap1, at_ap1, br0, "10.1.2.100/24", "00:00:00:00:02:03") > > AT_CHECK([ovs-vsctl set bridge br0 > other-config:hwaddr="00:00:00:00:00:01"]) > AT_CHECK([ip addr add dev br0 "172.31.1.100/24"]) > AT_CHECK([ip addr add dev br0 "172.31.2.100/24"]) > AT_CHECK([ip link set dev br0 up]) > > ADD_NATIVE_TUNNEL([vxlan], [at_vxlan_fp0], [at_fp0], [172.31.1.100], [ > 10.1.1.1/24], > [id 0 dstport 4789]) > ADD_NATIVE_TUNNEL([vxlan], [at_vxlan_fp1], [at_fp1], [17
Re: [ovs-dev] tunneling: RFC: Handle fully specified VxLAN tunnel port
Thanks William. I am trying out your suggestions. Will keep you posted how it goes. Meanwhile, I found another issue without any of my changes related to flooding and multiple tunnels in the same bridge. So, I initiated separate discussion. Would you mind comment on my flooding issue. I am thinking, if that issue is resolved, my Tx and Rx logic would also get simplified considerably. Here is the link <https://mail.openvswitch.org/pipermail/ovs-dev/2020-May/370067.html> for the flooding issue. -Vasu *Vasu Dasari* On Mon, May 4, 2020 at 7:03 PM William Tu wrote: > On Fri, May 01, 2020 at 02:40:41PM -0400, Vasu Dasari wrote: > > Thanks William for your comments. > > > > > > *Vasu Dasari* > > > > > > On Fri, May 1, 2020 at 11:52 AM William Tu wrote: > > > > > On Thu, Apr 30, 2020 at 08:42:04AM -0400, Vasu Dasari wrote: > > > > Hi, > > > > > > > > I am trying to implement a functionality, where in if user specifies > port > > > > through which a VxLAN encapsulated packet can be sent out, then use > that > > > > port rather than going through routing procedure. > > > > > > > > ovs-vsctl add-port br0 at_vxlan_fp1 -- \ > > > > set int at_vxlan_fp1 type=vxlan \ > > > > options:remote_ip=172.32.2.1 options:local_ip=172.32.2.100 \ > > > > options:dst_mac=00:00:00:00:01:02 > > > options:src_mac=00:00:00:00:01:01 > > > > \ > > > > options:out_port=1 > > > > > > > Why do you need to add dst_mac and src_mac? > > > Usually in the OVS kernel datapath case, OVS will consult the Linux > > > kernel's > > > arp table and get the src/dst mac address. > > > What if the manually set dst_mac here is different than the entry in > > > kernel? > > > > > > > > The goal is not to use Linux kernel's capabilities to determine which > path > > the tunnel to take. > > > > Imagine a set of switches in a fabric controlled by a controller and it > is > > used primarily for L2 services and some L3 services. If I were to use > Linux > > kernel to dictate which path to take, it would lead to using one bond or > a > > physical interface all the time for a particular destination switch. By > > doing so, there is no fabric diversity. Hence, as controller has view of > > the network, it can dictate which path/topology to take for a particular > L2 > > or L3 service. By using virtualized the fabric, I do not have to worry > > about about Mac pollution and loops (I can detail this separately if > > needed). And hence wanted to use VxLAN. > > > I see your use case, thanks! > William > > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] OVS Userspace: Usecase with multiple vxlan tunnels
Hi, I am trying a userspace vxlan test case scenario as follows. ap0, fp0, ap1 and fp1 are namespaces where in packets from ap0 are sent to fp0 over vxlan tunnel and packets from ap1 to fp1 are sent over second vxlan tunnel. And br0 for the bridge is handling ARP, route, etc. Note that br0 has two addresses on assigned to it. On executing the script with following command: sudo make -s -C _build-gcc/ check-system-userspace TESTSUITEFLAGS='-k "modified ping over vxlan tunnel"' I see that OVS times out and leaving behind br0 and ovs-netdev interfaces. But, if I comment out the one of the addresses on br0 at least the script will be successful but the ping on second tunnel will not be successful. My question is: 1. Is this use case supported in userspace OVS mode? 2. Am I missing something in configuration? Thanks -Vasu +--+ +---+ | | +---+ |ap0+--+ +--+fp0| +---+ | | +---+ | ovs | +---+ | br0 | +---+ |ap1+--+ +--+fp1| +---+ | | +---+ +--+ == AT_SETUP([datapath - modified ping over vxlan tunnel]) OVS_CHECK_VXLAN() OVS_TRAFFIC_VSWITCHD_START() ADD_NAMESPACES(at_fp0, at_fp1, at_ap0, at_ap1) dnl Set up underlay link from host into the namespace using veth pair. ADD_VETH(fp0, at_fp0, br0, "172.31.1.1/24", "00:00:00:00:01:02") ADD_VETH(ap0, at_ap0, br0, "10.1.1.100/24", "00:00:00:00:01:03") ADD_VETH(fp1, at_fp1, br0, "172.31.2.1/24", "00:00:00:00:02:02") ADD_VETH(ap1, at_ap1, br0, "10.1.2.100/24", "00:00:00:00:02:03") AT_CHECK([ovs-vsctl set bridge br0 other-config:hwaddr="00:00:00:00:00:01"]) AT_CHECK([ip addr add dev br0 "172.31.1.100/24"]) AT_CHECK([ip addr add dev br0 "172.31.2.100/24"]) AT_CHECK([ip link set dev br0 up]) ADD_NATIVE_TUNNEL([vxlan], [at_vxlan_fp0], [at_fp0], [172.31.1.100], [ 10.1.1.1/24], [id 0 dstport 4789]) ADD_NATIVE_TUNNEL([vxlan], [at_vxlan_fp1], [at_fp1], [172.31.2.100], [ 10.1.2.1/24], [id 0 dstport 4789]) dnl AT_CHECK([ovs-appctl vlog/set tnl_ports:dbg dpif_netdev:dbg ofproto_dpif_upcall:dbg tunnel:dbg]) dnl NS_CHECK_EXEC([at_fp1], [arp -s 172.31.2.100 00:00:00:00:00:01]) AT_CHECK([ovs-vsctl add-port br0 at_vxlan_fp0 -- \ set int at_vxlan_fp0 type=vxlan options:remote_ip=172.31.1.1]) AT_CHECK([ovs-vsctl add-port br0 at_vxlan_fp1 -- \ set int at_vxlan_fp1 type=vxlan options:remote_ip=172.31.2.1]) AT_DATA([flows.txt], [dnl priority=0,actions=normal ]) OVS_TRAFFIC_VSWITCHD_STOP AT_CLEANUP *Vasu Dasari* ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] tunneling: RFC: Handle fully specified VxLAN tunnel port
William, My comments are inline. Thanks. On Fri, May 1, 2020 at 12:01 PM William Tu wrote: > On Thu, Apr 30, 2020 at 08:52:38AM -0400, Vasu Dasari wrote: > > This email is with the technical difficulty I am having with supporting > > above feature. > > > > I have implemented all infrastructure necessary to support the > > CLI, netdev-vport, netdev-native-tnl, etc, and currently debugging my way > > through this. > > > > I am stuck in ofproto-dpif-xlate::native_tunnel_output(). What I see is > > that, although this function has all the parameters needed to create > > encapsulation header and know which odp_port to send it out of, it would > > still rely on "NORMAL" flow to send out the packet. And "NORMAL" flow > > relies on Mac learning table to figure out whether to flood or send it > out > > of a learned port. > > > > In this new case I am trying out, encap-dst-mac is not programmed in > > Mac-learning table(as the encap-dst-mac and out_port are explicitly > > specified and can be retrieved from netdev directly. And hence, > > xlate_normal() would flood the packet out of all ports and would never > > resolve dst-mac address as IP infrastructure on local machine is not > > configured for the source-ip address. > > > > My question is: > > 1. How can I accomplish sending out encapsulated frame without going > > through "NORMAL" processing? > > I don't think you need NORMAL flow. > You can always add OpenFlow rules to redirect packets to your tunnel port. > I am using a flow of this sort to direct access side traffic to a vxlan tunnel port. ovs-ofctl add-flow br0 priority=1,in_port=ovs-ap0,actions=at_vxlan_fp1 But, at_vxlan_fp1 is a virtual-port riding on a physical port "out_port". There is a lot of logic in native_tunnel_output() which I do not claim to understand completely but understanding that part with experimentation. For the packets to move from at_vxlan_fp to "out_port" leave the switch from "out_port" I think we need "NORMAL" flow. To prove out the idea, I have added a new field called "out_ofp_port" to xlate_ctx data structure in ofproto-dpif-xlate.c, and this field would be used to carry the out_ofp_port as passed by the caller, regardless of what Mac-learning table says. And this solved the transmit problem. Now I am have problem with receiving, that is, being able to classify the packet arriving on a physical port and map it to vxlan virtual port. Looks like this determination is done in classifier_rules. Currently trying to understand that logic. Any pointers to help me get there, it would be great. Thanks, -Vasu > > 2. Any suggestions on how can I go about getting this done? > > > > Thanks > > -Vasu > > > > *Vasu Dasari* > > > > > > On Thu, Apr 30, 2020 at 8:42 AM Vasu Dasari wrote: > > > > > Hi, > > > > > > I am trying to implement a functionality, where in if user specifies > port > > > through which a VxLAN encapsulated packet can be sent out, then use > that > > > port rather than going through routing procedure. > > > > > > ovs-vsctl add-port br0 at_vxlan_fp1 -- \ > > > set int at_vxlan_fp1 type=vxlan \ > > > options:remote_ip=172.32.2.1 options:local_ip=172.32.2.100 \ > > > options:dst_mac=00:00:00:00:01:02 > > > options:src_mac=00:00:00:00:01:01 \ > > > options:out_port=1 > > > > > > This would create a fully specified tunnel port, it includes all L2 > and L3 > > > parameters needed to create encapsulated frame. This kind of syntax > would > > > mimic what is supported by off the shelf hardware like Broadcom. I also > > > noticed that pica8's Openflow switch supports this kind of syntax as > well (Configuring > > > VXLAN <https://docs.pica8.com/display/PICOS2111cg/Configuring+VXLAN>) > > > > > > And the user could create flows of this sort to transport user packets > > > with VxLAN payload: > > > > > > ovs-ofctl add-flow br0 priority=1,in_port=ovs-ap0,actions=at_vxlan_fp1 > > > ovs-ofctl add-flow br0 priority=1,in_port=at_vxlan_fp1,actions=ovs-ap0 > > > > > > > > > I have initiated a discussion for this kind of request in June, 2019 > at, ovs-discuss > > > thread > > > < > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048754.html>. > > > And would like to use this thread for design and any other comments. > > > > > > > > > Please let me know what you think. > > > > > > > > > Thanks > > > > > > -Vasu > > > > > > > > > *Vasu Dasari* > > > > > ___ > > dev mailing list > > d...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] tunneling: RFC: Handle fully specified VxLAN tunnel port
Thanks William for your comments. *Vasu Dasari* On Fri, May 1, 2020 at 11:52 AM William Tu wrote: > On Thu, Apr 30, 2020 at 08:42:04AM -0400, Vasu Dasari wrote: > > Hi, > > > > I am trying to implement a functionality, where in if user specifies port > > through which a VxLAN encapsulated packet can be sent out, then use that > > port rather than going through routing procedure. > > > > ovs-vsctl add-port br0 at_vxlan_fp1 -- \ > > set int at_vxlan_fp1 type=vxlan \ > > options:remote_ip=172.32.2.1 options:local_ip=172.32.2.100 \ > > options:dst_mac=00:00:00:00:01:02 > options:src_mac=00:00:00:00:01:01 > > \ > > options:out_port=1 > > > Why do you need to add dst_mac and src_mac? > Usually in the OVS kernel datapath case, OVS will consult the Linux > kernel's > arp table and get the src/dst mac address. > What if the manually set dst_mac here is different than the entry in > kernel? > > The goal is not to use Linux kernel's capabilities to determine which path the tunnel to take. Imagine a set of switches in a fabric controlled by a controller and it is used primarily for L2 services and some L3 services. If I were to use Linux kernel to dictate which path to take, it would lead to using one bond or a physical interface all the time for a particular destination switch. By doing so, there is no fabric diversity. Hence, as controller has view of the network, it can dictate which path/topology to take for a particular L2 or L3 service. By using virtualized the fabric, I do not have to worry about about Mac pollution and loops (I can detail this separately if needed). And hence wanted to use VxLAN. > > This would create a fully specified tunnel port, it includes all L2 and > L3 > > parameters needed to create encapsulated frame. This kind of syntax would > > mimic what is supported by off the shelf hardware like Broadcom. I also > > noticed that pica8's Openflow switch supports this kind of syntax as > > well (Configuring > > VXLAN <https://docs.pica8.com/display/PICOS2111cg/Configuring+VXLAN>) > > > > And the user could create flows of this sort to transport user packets > with > > VxLAN payload: > > > > ovs-ofctl add-flow br0 priority=1,in_port=ovs-ap0,actions=at_vxlan_fp1 > > ovs-ofctl add-flow br0 priority=1,in_port=at_vxlan_fp1,actions=ovs-ap0 > > > > > > I have initiated a discussion for this kind of request in June, 2019 > > at, ovs-discuss > > thread > > < > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048754.html>. > > And would like to use this thread for design and any other comments. > > > > > > Please let me know what you think. > > > > > > Thanks > > > > -Vasu > > > > > > *Vasu Dasari* > > ___ > > dev mailing list > > d...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] tunneling: RFC: Handle fully specified VxLAN tunnel port
This email is with the technical difficulty I am having with supporting above feature. I have implemented all infrastructure necessary to support the CLI, netdev-vport, netdev-native-tnl, etc, and currently debugging my way through this. I am stuck in ofproto-dpif-xlate::native_tunnel_output(). What I see is that, although this function has all the parameters needed to create encapsulation header and know which odp_port to send it out of, it would still rely on "NORMAL" flow to send out the packet. And "NORMAL" flow relies on Mac learning table to figure out whether to flood or send it out of a learned port. In this new case I am trying out, encap-dst-mac is not programmed in Mac-learning table(as the encap-dst-mac and out_port are explicitly specified and can be retrieved from netdev directly. And hence, xlate_normal() would flood the packet out of all ports and would never resolve dst-mac address as IP infrastructure on local machine is not configured for the source-ip address. My question is: 1. How can I accomplish sending out encapsulated frame without going through "NORMAL" processing? 2. Any suggestions on how can I go about getting this done? Thanks -Vasu *Vasu Dasari* On Thu, Apr 30, 2020 at 8:42 AM Vasu Dasari wrote: > Hi, > > I am trying to implement a functionality, where in if user specifies port > through which a VxLAN encapsulated packet can be sent out, then use that > port rather than going through routing procedure. > > ovs-vsctl add-port br0 at_vxlan_fp1 -- \ > set int at_vxlan_fp1 type=vxlan \ > options:remote_ip=172.32.2.1 options:local_ip=172.32.2.100 \ > options:dst_mac=00:00:00:00:01:02 > options:src_mac=00:00:00:00:01:01 \ > options:out_port=1 > > This would create a fully specified tunnel port, it includes all L2 and L3 > parameters needed to create encapsulated frame. This kind of syntax would > mimic what is supported by off the shelf hardware like Broadcom. I also > noticed that pica8's Openflow switch supports this kind of syntax as well > (Configuring > VXLAN <https://docs.pica8.com/display/PICOS2111cg/Configuring+VXLAN>) > > And the user could create flows of this sort to transport user packets > with VxLAN payload: > > ovs-ofctl add-flow br0 priority=1,in_port=ovs-ap0,actions=at_vxlan_fp1 > ovs-ofctl add-flow br0 priority=1,in_port=at_vxlan_fp1,actions=ovs-ap0 > > > I have initiated a discussion for this kind of request in June, 2019 at, > ovs-discuss > thread > <https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048754.html>. > And would like to use this thread for design and any other comments. > > > Please let me know what you think. > > > Thanks > > -Vasu > > > *Vasu Dasari* > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] tunneling: RFC: Handle fully specified VxLAN tunnel port
Hi, I am trying to implement a functionality, where in if user specifies port through which a VxLAN encapsulated packet can be sent out, then use that port rather than going through routing procedure. ovs-vsctl add-port br0 at_vxlan_fp1 -- \ set int at_vxlan_fp1 type=vxlan \ options:remote_ip=172.32.2.1 options:local_ip=172.32.2.100 \ options:dst_mac=00:00:00:00:01:02 options:src_mac=00:00:00:00:01:01 \ options:out_port=1 This would create a fully specified tunnel port, it includes all L2 and L3 parameters needed to create encapsulated frame. This kind of syntax would mimic what is supported by off the shelf hardware like Broadcom. I also noticed that pica8's Openflow switch supports this kind of syntax as well (Configuring VXLAN <https://docs.pica8.com/display/PICOS2111cg/Configuring+VXLAN>) And the user could create flows of this sort to transport user packets with VxLAN payload: ovs-ofctl add-flow br0 priority=1,in_port=ovs-ap0,actions=at_vxlan_fp1 ovs-ofctl add-flow br0 priority=1,in_port=at_vxlan_fp1,actions=ovs-ap0 I have initiated a discussion for this kind of request in June, 2019 at, ovs-discuss thread <https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048754.html>. And would like to use this thread for design and any other comments. Please let me know what you think. Thanks -Vasu *Vasu Dasari* ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Failed to execute unit test: system-traffic.at: conntrack - floating IP
Thanks William. Yes. I am running Ubuntu 18.04LTS and iproute2 version is 4.15, which is more than 2 years old. I will upgrade the system and try out. -Vasu On Mon, Apr 27, 2020 at 8:42 PM William Tu wrote: > On Mon, Apr 27, 2020 at 11:54 AM Vasu Dasari wrote: > > > > Hi, > > > > I am running into an error when I try to run the system-traffic test > case - > > "conntrack - floating IP". Actually, any test case which is using this in > > the testsuite is failing: > > ADD_VETH(p0, at_ns0, br0, "10.1.1.1/24", "f0:00:00:01:01:01") > > > > Command used to run the test: > > sudo make -C _build-gcc/ check-system-userspace TESTSUITEFLAGS='-k > > "conntrack - floating IP"' > > Ububtu Kernel: 5.3.0-46-generic > > OVS Version: Latest master > > > > Relevant supporting log from system-userspace-testsuite.log > > > > = > > ../../tests/system-traffic.at:5757: ip netns exec at_ns0 sh << > > NS_EXEC_HEREDOC > > ip link set dev p0 address "f0:00:00:01:01:01" > > NS_EXEC_HEREDOC > > --- /dev/null 2020-04-27 14:44:02.898140777 -0400 > > +++ > > > /opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/at-groups/120/stderr > > 2020-04-27 14:44:33.432320411 -0400 > > @@ -0,0 +1 @@ > > +Invalid address length 6 - must be 42401 bytes > > Hi Vasu, > > This is due to a bug in iproute2. > Can you update to the latest version? > see > Documentation/topics/testing.rst > " > Many of the kernel tests are dependent on the utilities present in the > iproute2 package, especially the 'ip' command. If there are many > otherwise unexplained errors it may be necessary to update the iproute2 > package utilities on the system. It is beyond the scope of this > documentation to explain all that is necessary to build and install > an updated iproute2 utilities package. The package is available from > the Linux kernel organization open source git repositories. > https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git > " > > ../../tests/system-traffic.at:5757: exit code was 1, expected 0 > > = > > > > Found a reference to this kind of error at > > https://bugzilla.redhat.com/show_bug.cgi?id=1550097 > > This was from last April. > > > > If I execute the command from bash, the same is successful: > > > > $ sudo ip netns exec at_ns0 bash > > $ ip link set dev p0 address "f0:00:00:01:01:01" > > $ ip link show p0 > > 11: p0@if10: mtu 1500 qdisc noqueue > state > > UP mode DEFAULT group default qlen 1000 > > link/ether f0:00:00:01:01:01 brd ff:ff:ff:ff:ff:ff link-netnsid 0 > > > > > > Any idea why this command is failing only in OVS environment? > > > > Thanks > > -Vasu > > > > *Vasu Dasari* > > ___ > > dev mailing list > > d...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Failed to execute unit test: system-traffic.at: conntrack - floating IP
Hi, I am running into an error when I try to run the system-traffic test case - "conntrack - floating IP". Actually, any test case which is using this in the testsuite is failing: ADD_VETH(p0, at_ns0, br0, "10.1.1.1/24", "f0:00:00:01:01:01") Command used to run the test: sudo make -C _build-gcc/ check-system-userspace TESTSUITEFLAGS='-k "conntrack - floating IP"' Ububtu Kernel: 5.3.0-46-generic OVS Version: Latest master Relevant supporting log from system-userspace-testsuite.log = ../../tests/system-traffic.at:5757: ip netns exec at_ns0 sh << NS_EXEC_HEREDOC ip link set dev p0 address "f0:00:00:01:01:01" NS_EXEC_HEREDOC --- /dev/null 2020-04-27 14:44:02.898140777 -0400 +++ /opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/at-groups/120/stderr 2020-04-27 14:44:33.432320411 -0400 @@ -0,0 +1 @@ +Invalid address length 6 - must be 42401 bytes ../../tests/system-traffic.at:5757: exit code was 1, expected 0 = Found a reference to this kind of error at https://bugzilla.redhat.com/show_bug.cgi?id=1550097 This was from last April. If I execute the command from bash, the same is successful: $ sudo ip netns exec at_ns0 bash $ ip link set dev p0 address "f0:00:00:01:01:01" $ ip link show p0 11: p0@if10: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether f0:00:00:01:01:01 brd ff:ff:ff:ff:ff:ff link-netnsid 0 Any idea why this command is failing only in OVS environment? Thanks -Vasu *Vasu Dasari* ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] tnl-neigh: Use outgoing ofproto version.
Looks good Flavio. Acked-By: Vasu Dasari Thanks -Vasu *Vasu Dasari* On Tue, Aug 13, 2019 at 12:45 PM Flavio Leitner via dev < ovs-dev@openvswitch.org> wrote: > On Tue, Aug 13, 2019 at 01:34:04PM -0300, Flavio Leitner via dev wrote: > > When a packet needs to be encapsulated in userspace, the endpoint > > address needs to be resolved to fill in the headers. If it is not, > > then currently OvS sends either a Neighbor Solicitation (IPv6) > > or an ARP Query (IPv4) to resolve it. > > > > The problem is that the NS/ARP packet will go through the flow > > rules in the new bridge, but inheriting the ofproto table version > > from the original packet to be encapsulated. When those versions > > don't match, the result is unexpected because no flow rules might > > be visible, which would cause the default table rule to be used > > to drop the packet. Or only part of the flow rules would be visible > > and so on. > > > > Since the NS/ARP packet is created by OvS and will be injected in > > the outgoing bridge, use the corresponding ofproto version instead. > > Hi, > > Please backport this up to 2.9 at least. > Thanks, > fbl > > > ___ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4] tnl-neigh-cache: Purge learnt neighbors when port/bridge is deleted
Thanks Ben. *Vasu Dasari* On Mon, Jul 22, 2019 at 12:30 PM Ben Pfaff wrote: > On Tue, Jul 16, 2019 at 10:54:31AM -0400, Vasu Dasari wrote: > > Say an ARP entry is learnt on a OVS port and when such a port is deleted, > > learnt entry should be removed from the port. It would have be aged out > after > > ARP ageout time. This code will clean up immediately. > > > > Added test case(tunnel - neighbor entry add and deletion) in tunnel.at, > to > > verify neighbors are added and removed on deletion of a ports and > bridges. > > > > Discussion for this addition is at: > > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048754.html > > > > Signed-off-by: Vasu Dasari > > Reviewed-by: Flavio Fernandes > > Reviewed-by: Ben Pfaff > > Applied to master, thanks! > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] ovs-macros: An option to suspend test execution on error
Thanks Ben and Aaron for your review and comments. *Vasu Dasari* On Tue, Jul 16, 2019 at 12:57 PM Ben Pfaff wrote: > On Mon, Jul 15, 2019 at 05:15:01PM -0400, Vasu Dasari wrote: > > Origins for this patch are captured at > > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048923.html > . > > > > Summarizing here, when a test fails, it would be good to pause test > execution > > and let the developer poke around the system to see current status of > system. > > Thanks a lot! > > I updated the documentation a bit because it talked about the userspace > datapath testsuite even though it was part of the documentation for the > main set of unit tests. > > I applied this to master, thanks again! > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v4] tnl-neigh-cache: Purge learnt neighbors when port/bridge is deleted
Say an ARP entry is learnt on a OVS port and when such a port is deleted,
learnt entry should be removed from the port. It would have be aged out after
ARP ageout time. This code will clean up immediately.
Added test case(tunnel - neighbor entry add and deletion) in tunnel.at, to
verify neighbors are added and removed on deletion of a ports and bridges.
Discussion for this addition is at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048754.html
Signed-off-by: Vasu Dasari
Reviewed-by: Flavio Fernandes
Reviewed-by: Ben Pfaff
---
---
v1 -> v2:
Incorporate robot comments. Verified the commit with utilities/checkpatch.py
-1
v2 -> v3:
Incorporate review comments from Flavio and Ben. Discussions at:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360318.html
https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360424.html
v3 -> v4:
Reworded Acked-by to Reviewed-by in commit description.
---
lib/tnl-neigh-cache.c| 20 +++
lib/tnl-neigh-cache.h| 1 +
ofproto/ofproto-dpif-xlate.c | 3 +++
tests/tunnel.at | 47
4 files changed, 71 insertions(+)
diff --git a/lib/tnl-neigh-cache.c b/lib/tnl-neigh-cache.c
index b28f9f1bb..5bda4af7e 100644
--- a/lib/tnl-neigh-cache.c
+++ b/lib/tnl-neigh-cache.c
@@ -220,6 +220,26 @@ tnl_neigh_cache_run(void)
}
}
+void
+tnl_neigh_flush(const char br_name[IFNAMSIZ])
+{
+struct tnl_neigh_entry *neigh;
+bool changed = false;
+
+ovs_mutex_lock();
+CMAP_FOR_EACH (neigh, cmap_node, ) {
+if (!strcmp(neigh->br_name, br_name)) {
+tnl_neigh_delete(neigh);
+changed = true;
+}
+}
+ovs_mutex_unlock();
+
+if (changed) {
+seq_change(tnl_conf_seq);
+}
+}
+
static void
tnl_neigh_cache_flush(struct unixctl_conn *conn, int argc OVS_UNUSED,
const char *argv[] OVS_UNUSED, void *aux OVS_UNUSED)
diff --git a/lib/tnl-neigh-cache.h b/lib/tnl-neigh-cache.h
index fee8e6a6f..ded9c2f86 100644
--- a/lib/tnl-neigh-cache.h
+++ b/lib/tnl-neigh-cache.h
@@ -37,5 +37,6 @@ int tnl_neigh_lookup(const char dev_name[], const struct
in6_addr *dst,
struct eth_addr *mac);
void tnl_neigh_cache_init(void);
void tnl_neigh_cache_run(void);
+void tnl_neigh_flush(const char dev_name[]);
#endif
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 73966a4e8..28a7fdd84 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -1481,6 +1481,9 @@ xlate_ofport_remove(struct ofport_dpif *ofport)
ovs_assert(new_xcfg);
xport = xport_lookup(new_xcfg, ofport);
+if (xport) {
+tnl_neigh_flush(netdev_get_name(xport->netdev));
+}
xlate_xport_remove(new_xcfg, xport);
}
diff --git a/tests/tunnel.at b/tests/tunnel.at
index 035c54f67..fc6f87936 100644
--- a/tests/tunnel.at
+++ b/tests/tunnel.at
@@ -920,3 +920,50 @@ dnl which is not correct
OVS_VSWITCHD_STOP
AT_CLEANUP
+
+AT_SETUP([tunnel - neighbor entry add and deletion])
+OVS_VSWITCHD_START([add-port br0 p1 -- set Interface p1 type=gre \
+options:remote_ip=1.1.1.1 options:local_ip=2.2.2.2 \
+options:key=5 ofport_request=1 \
+-- add-port br0 p2 -- set Interface p2 type=gre \
+options:local_ip=3.3.3.3 options:remote_ip=4.4.4.4 \
+ofport_request=2])
+AT_CHECK([ovs-vsctl add-br br1 -- set bridge br1 datapath_type=dummy], [0])
+
+dnl Populate tunnel neighbor cache table
+AT_CHECK([
+ovs-appctl tnl/arp/set p1 10.0.0.1 00:00:10:00:00:01
+ovs-appctl tnl/arp/set p1 10.0.0.2 00:00:10:00:00:02
+ovs-appctl tnl/arp/set p2 10.0.1.1 00:00:10:00:01:01
+ovs-appctl tnl/arp/set br0 10.0.2.1 00:00:10:00:02:01
+ovs-appctl tnl/arp/set br0 10.0.2.2 00:00:10:00:02:02
+ovs-appctl tnl/arp/set br1 20.0.0.1 00:00:20:00:00:01
+], [0], [stdout])
+
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | sort], [0], [dnl
+10.0.0.1 00:00:10:00:00:01 p1
+10.0.0.2 00:00:10:00:00:02 p1
+10.0.1.1 00:00:10:00:01:01 p2
+10.0.2.1 00:00:10:00:02:01 br0
+10.0.2.2 00:00:10:00:02:02 br0
+20.0.0.1 00:00:20:00:00:01 br1
+])
+
+dnl neighbor table after deleting port p1
+AT_CHECK([ovs-vsctl del-port br0 p1],[0], [stdout])
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | grep -w p1 | sort], [0], [dnl
+])
+
+dnl neighbor table after deleting bridge br0
+AT_CHECK([ovs-vsctl del-br br0],[0], [stdout])
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | sort], [0], [dnl
+20.0.0.1 00:00:20:00:00:01 br1
+])
+
+dnl neighbor table after deleting bridge br1
+AT_CHECK([ovs-vsctl del-br br1],[0], [stdout])
+AT_CH
Re: [ovs-dev] [PATCH v1] ovs-macros: An option to suspend test execution on error
Done. Patch is at: [ovs-dev] [PATCH v2] ovs-macros: An option to suspend test execution on error <https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360720.html> <https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360720.html> *Vasu Dasari* On Mon, Jul 15, 2019 at 4:12 PM Ben Pfaff wrote: > I'm not Aaron but that does seems reasonable to me. > > On Mon, Jul 15, 2019 at 04:01:26PM -0400, Vasu Dasari wrote: > > Aaron, > > > > I see that documentation for topics/testing is mostly one liners and > > precise. And hence I chose one liner as well. If I have to put all your > > recommended test, I think it is better to have a subsection, "Debugging > > unit tests". What do you think? > > > > -Vasu > > > > *Vasu Dasari* > > > > > > On Mon, Jul 15, 2019 at 3:48 PM Aaron Conole wrote: > > > > > Hi Vasu, > > > > > > Vasu Dasari writes: > > > > > > > Origins for this patch are captured at > > > > > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048923.html > > > . > > > > > > > > Summarizing here, when a test fails, it would be good to pause test > > > execution > > > > and let the developer poke around the system to see current status of > > > system. > > > > > > > > As part of this patch, made a small tweaks to ovs-macros.at, so that > > > when test > > > > suite fails, ovs_on_exit() function will be called. And in this > > > function, a check > > > > is made to see if an environment variable to OVS_PAUSE_TEST is set. > If > > > it is > > > > set, then test suite is paused and will continue to wait for user > input > > > > Ctrl-D. Meanwhile user can poke around the system to see why test > case > > > has > > > > failed. Once done with investigation, user can press ctrl-d to > cleanup > > > the > > > > test suite. > > > > > > > > > > From this point > > >vv > > > > > > > For example, to re-run test case 139: > > > > > > > > export OVS_PAUSE_TEST=1 > > > > cd tests/system-userspace-testsuite.dir/139 > > > > sudo -E ./run > > > > > > > > When error occurs, above command would display something like this: > > > > = > > > > Set environment variable to use various ovs utilities > > > > export > > > > OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139 > > > > Press ctrl-d to continue: > > > > > > > > = > > > > And from another window, one can execute ovs-xxx commands like: > > > > export > > > > OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139 > > > > $ ovs-ofctl dump-ports br0 > > > > . > > > > . > > > > > > > > To be able to pause while performing `make check`, one can do: > > > > $ OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v' > > > > > > > > > > To here ^^ > > > > > > I would propose to put this information in the documentation. A new > > > developer may not actually trawl through the commits, but this > > > information would help such a developer (or even a not-so-new > developer, > > > like me). > > > > > > > Signed-off-by: Vasu Dasari > > > > Reviewed-by: Ben Pfaff > > > > --- > > > > v0 -> v1: > > > > Discussion at: > > > https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360589.html > > > > 1. Incorporated review commanets from Ben. > > > > 2. Changed topics/testing.rst to document this trick > > > > 3. Made this trick work via "make check" as well, by issuing command: > > > "OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v'" > > > > > > > > --- > > > > Documentation/topics/testing.rst | 6 ++ > > > > tests/ovs-macros.at | 24 +++- > > > > 2 files changed, 29 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/Documentation/topics/testing.rst > > > b/Documentation/topics/testing.rst > > > > index a8892e1c1..058b3986f 100644 > > > > --- a/Documentation/topics/testing
[ovs-dev] [PATCH v2] ovs-macros: An option to suspend test execution on error
Origins for this patch are captured at
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048923.html.
Summarizing here, when a test fails, it would be good to pause test execution
and let the developer poke around the system to see current status of system.
As part of this patch, made a small tweaks to ovs-macros.at, so that when test
suite fails, ovs_on_exit() function will be called. And in this function, a
check
is made to see if an environment variable to OVS_PAUSE_TEST is set. If it is
set, then test suite is paused and will continue to wait for user input
Ctrl-D. Meanwhile user can poke around the system to see why test case has
failed. Once done with investigation, user can press ctrl-d to cleanup the
test suite.
For example, to re-run test case 139:
export OVS_PAUSE_TEST=1
cd tests/system-userspace-testsuite.dir/139
sudo -E ./run
When error occurs, above command would display something like this:
=
Set environment variable to use various ovs utilities
export
OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
Press ENTER to continue:
=
And from another window, one can execute ovs-xxx commands like:
export
OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
$ ovs-ofctl dump-ports br0
.
.
To be able to pause while performing `make check`, one can do:
$ OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v'
Signed-off-by: Vasu Dasari
Reviewed-by: Ben Pfaff
Reviewed-by: Aaron Conole
---
v0 -> v1:
Discussion at:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360589.html
1. Incorporated review commanets from Ben.
2. Changed topics/testing.rst to document this trick
3. Made this trick work via "make check" as well, by issuing command:
"OVS_PAUSE_TEST=1
make check TESTSUITEFLAGS='-v'"
v1 -> v2:
Discussion at:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360705.html
1. Added a subsection, "Debugging unit tests"
2. Renamed $as_echo to just echo. AS_ECHO is not suported in autoconf 2.69.11.
And, we are not gainin
g anything from AS_ECHO in this code, just using echo.
---
Documentation/topics/testing.rst | 31 +++
tests/ovs-macros.at | 24 +++-
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/Documentation/topics/testing.rst b/Documentation/topics/testing.rst
index a8892e1c1..73077042c 100644
--- a/Documentation/topics/testing.rst
+++ b/Documentation/topics/testing.rst
@@ -81,6 +81,37 @@ To see a complete list of test options, run::
The results of a testing run are reported in ``tests/testsuite.log``. Report
report test failures as bugs and include the ``testsuite.log`` in your report.
+Debugging unit tests
+
+
+To initiate debugging from artifacts generated from `make check` run, use
+following instructions. For example, to re-run test case 139::
+
+ export OVS_PAUSE_TEST=1
+ cd tests/system-userspace-testsuite.dir/139
+ sudo -E ./run
+
+When error occurs, above command would display something like this::
+
+ Set environment variable to use various ovs utilities
+ export
OVS_RUNDIR=/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
+ Press ENTER to continue:
+
+And from another window, one can execute ovs-xxx commands like::
+
+ export
OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
+ $ ovs-ofctl dump-ports br0
+ .
+ .
+
+Once done with investigation, press ENTER to perform cleanup operation.
+
+To be able to pause on error while performing `make check`, one can do::
+
+ $ OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v'
+
+and then follow similar on screen instructions
+
.. note::
Sometimes a few tests may fail on some runs but not others. This is usually a
bug in the testsuite, not a bug in Open vSwitch itself. If you find that a
diff --git a/tests/ovs-macros.at b/tests/ovs-macros.at
index 10593429d..b6add7fda 100644
--- a/tests/ovs-macros.at
+++ b/tests/ovs-macros.at
@@ -35,11 +35,33 @@ m4_divert_push([PREPARE_TESTS])
# directory.
ovs_init() {
ovs_base=`pwd`
-trap '. "$ovs_base/cleanup"' 0
+trap ovs_on_exit 0
: > cleanup
ovs_setenv
}
+# Catch testsuite error condition and cleanup test environment by tearing down
+# all interfaces and processes spawned.
+# User has an option to leave the test environment in error state so that
system
+# can be poked around to get more information. User can enable this option by
setting
+# environment variable OVS_PAUSE_TEST=1. User needs to press CTRL-D to resume
the
+# cleanup operation.
+ovs_pause() {
+echo "="
+echo "Set following environment variable to use various ovs utilities"
+echo "export OVS_RUNDIR=$o
Re: [ovs-dev] [PATCH v1] ovs-macros: An option to suspend test execution on error
Aaron,
I see that documentation for topics/testing is mostly one liners and
precise. And hence I chose one liner as well. If I have to put all your
recommended test, I think it is better to have a subsection, "Debugging
unit tests". What do you think?
Ben,
Will do. Also, note that I am using at_verbose variable if we are in
verbose mode or not. If user has not run the test suite in verbose mode,
none of the instructions to set the OVS_RUNDIR variable, etc will appear on
screen, and hence user will not have a clue why script is pausing. So, I am
also qualifying the check for at_verbose variable. I hope it is ok to use
the at_verbose variable.
-Vasu
*Vasu Dasari*
On Mon, Jul 15, 2019 at 3:59 PM Ben Pfaff wrote:
> On Mon, Jul 15, 2019 at 03:22:42PM -0400, Vasu Dasari wrote:
> > Origins for this patch are captured at
> > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048923.html
> .
>
> ...
>
> Aaron provided helpful comments. In addition:
>
> > +ovs_pause() {
> > +$as_echo "="
> > +$as_echo "Set following environment variable to use various ovs
> utilities"
> > +$as_echo "export OVS_RUNDIR=$ovs_base"
> > +$as_echo "Press ENTER to continue: "
> > +read
> > +}
>
> The above uses $as_echo, which is what the AS_ECHO([...]) macro expands
> into. It is better to use AS_ECHO itself, since in theory the
> implementation could change in a later version of Autoconf.
>
> Thanks,
>
> Ben.
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1] ovs-macros: An option to suspend test execution on error
Aaron,
I see that documentation for topics/testing is mostly one liners and
precise. And hence I chose one liner as well. If I have to put all your
recommended test, I think it is better to have a subsection, "Debugging
unit tests". What do you think?
-Vasu
*Vasu Dasari*
On Mon, Jul 15, 2019 at 3:48 PM Aaron Conole wrote:
> Hi Vasu,
>
> Vasu Dasari writes:
>
> > Origins for this patch are captured at
> > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048923.html
> .
> >
> > Summarizing here, when a test fails, it would be good to pause test
> execution
> > and let the developer poke around the system to see current status of
> system.
> >
> > As part of this patch, made a small tweaks to ovs-macros.at, so that
> when test
> > suite fails, ovs_on_exit() function will be called. And in this
> function, a check
> > is made to see if an environment variable to OVS_PAUSE_TEST is set. If
> it is
> > set, then test suite is paused and will continue to wait for user input
> > Ctrl-D. Meanwhile user can poke around the system to see why test case
> has
> > failed. Once done with investigation, user can press ctrl-d to cleanup
> the
> > test suite.
> >
>
> From this point
>vv
>
> > For example, to re-run test case 139:
> >
> > export OVS_PAUSE_TEST=1
> > cd tests/system-userspace-testsuite.dir/139
> > sudo -E ./run
> >
> > When error occurs, above command would display something like this:
> > =
> > Set environment variable to use various ovs utilities
> > export
> OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
> > Press ctrl-d to continue:
> >
> > =
> > And from another window, one can execute ovs-xxx commands like:
> > export
> OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
> > $ ovs-ofctl dump-ports br0
> > .
> > .
> >
> > To be able to pause while performing `make check`, one can do:
> > $ OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v'
> >
>
> To here ^^
>
> I would propose to put this information in the documentation. A new
> developer may not actually trawl through the commits, but this
> information would help such a developer (or even a not-so-new developer,
> like me).
>
> > Signed-off-by: Vasu Dasari
> > Reviewed-by: Ben Pfaff
> > ---
> > v0 -> v1:
> > Discussion at:
> https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360589.html
> > 1. Incorporated review commanets from Ben.
> > 2. Changed topics/testing.rst to document this trick
> > 3. Made this trick work via "make check" as well, by issuing command:
> "OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v'"
> >
> > ---
> > Documentation/topics/testing.rst | 6 ++
> > tests/ovs-macros.at | 24 +++-
> > 2 files changed, 29 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/topics/testing.rst
> b/Documentation/topics/testing.rst
> > index a8892e1c1..058b3986f 100644
> > --- a/Documentation/topics/testing.rst
> > +++ b/Documentation/topics/testing.rst
> > @@ -74,6 +74,12 @@ To run tests matching a keyword, e.g. ``ovsdb``, run::
> >
> > $ make check TESTSUITEFLAGS='-k ovsdb'
> >
> > +To pause at a failing test (e.g. ``ovsdb``) and inspect the system in
> failed
> > +state, follow the instructions given out by issuing following command
> to use
> > +various ovs-* utilities::
> > +
> > +$ OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v -k ovsdb'
> > +
> > To see a complete list of test options, run::
> >
> > $ make check TESTSUITEFLAGS=--help
> > diff --git a/tests/ovs-macros.at b/tests/ovs-macros.at
> > index 10593429d..e58b0a1a0 100644
> > --- a/tests/ovs-macros.at
> > +++ b/tests/ovs-macros.at
> > @@ -35,11 +35,33 @@ m4_divert_push([PREPARE_TESTS])
> > # directory.
> > ovs_init() {
> > ovs_base=`pwd`
> > -trap '. "$ovs_base/cleanup"' 0
> > +trap ovs_on_exit 0
> > : > cleanup
> > ovs_setenv
> > }
> >
> > +# Catch testsuite error condition and cleanup test environment by
> tearing down
> > +# all interfaces and processes spawned.
> > +# User has an option to leave the test environment in error state so
> that system
> > +# can be poked around to get
[ovs-dev] [PATCH v1] ovs-macros: An option to suspend test execution on error
Origins for this patch are captured at
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048923.html.
Summarizing here, when a test fails, it would be good to pause test execution
and let the developer poke around the system to see current status of system.
As part of this patch, made a small tweaks to ovs-macros.at, so that when test
suite fails, ovs_on_exit() function will be called. And in this function, a
check
is made to see if an environment variable to OVS_PAUSE_TEST is set. If it is
set, then test suite is paused and will continue to wait for user input
Ctrl-D. Meanwhile user can poke around the system to see why test case has
failed. Once done with investigation, user can press ctrl-d to cleanup the
test suite.
For example, to re-run test case 139:
export OVS_PAUSE_TEST=1
cd tests/system-userspace-testsuite.dir/139
sudo -E ./run
When error occurs, above command would display something like this:
=
Set environment variable to use various ovs utilities
export
OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
Press ctrl-d to continue:
=
And from another window, one can execute ovs-xxx commands like:
export
OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
$ ovs-ofctl dump-ports br0
.
.
To be able to pause while performing `make check`, one can do:
$ OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v'
Signed-off-by: Vasu Dasari
Reviewed-by: Ben Pfaff
---
v0 -> v1:
Discussion at:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360589.html
1. Incorporated review commanets from Ben.
2. Changed topics/testing.rst to document this trick
3. Made this trick work via "make check" as well, by issuing command:
"OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v'"
---
Documentation/topics/testing.rst | 6 ++
tests/ovs-macros.at | 24 +++-
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/Documentation/topics/testing.rst b/Documentation/topics/testing.rst
index a8892e1c1..058b3986f 100644
--- a/Documentation/topics/testing.rst
+++ b/Documentation/topics/testing.rst
@@ -74,6 +74,12 @@ To run tests matching a keyword, e.g. ``ovsdb``, run::
$ make check TESTSUITEFLAGS='-k ovsdb'
+To pause at a failing test (e.g. ``ovsdb``) and inspect the system in failed
+state, follow the instructions given out by issuing following command to use
+various ovs-* utilities::
+
+$ OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v -k ovsdb'
+
To see a complete list of test options, run::
$ make check TESTSUITEFLAGS=--help
diff --git a/tests/ovs-macros.at b/tests/ovs-macros.at
index 10593429d..e58b0a1a0 100644
--- a/tests/ovs-macros.at
+++ b/tests/ovs-macros.at
@@ -35,11 +35,33 @@ m4_divert_push([PREPARE_TESTS])
# directory.
ovs_init() {
ovs_base=`pwd`
-trap '. "$ovs_base/cleanup"' 0
+trap ovs_on_exit 0
: > cleanup
ovs_setenv
}
+# Catch testsuite error condition and cleanup test environment by tearing down
+# all interfaces and processes spawned.
+# User has an option to leave the test environment in error state so that
system
+# can be poked around to get more information. User can enable this option by
setting
+# environment variable OVS_PAUSE_TEST=1. User needs to press CTRL-D to resume
the
+# cleanup operation.
+ovs_pause() {
+$as_echo "="
+$as_echo "Set following environment variable to use various ovs utilities"
+$as_echo "export OVS_RUNDIR=$ovs_base"
+$as_echo "Press ENTER to continue: "
+read
+}
+
+ovs_on_exit () {
+if [ ! -z "${OVS_PAUSE_TEST}" ] && [ -z $at_verbose ]; then
+trap '' INT
+ovs_pause
+fi
+. "$ovs_base/cleanup"
+}
+
# With no parameter or an empty parameter, sets the OVS_*DIR
# environment variables to point to $ovs_base, the base directory in
# which the test is running.
--
2.17.2 (Apple Git-113)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovs-macros: An option to suspend test execution on error
Please ignore this.
*Vasu Dasari*
On Mon, Jul 15, 2019 at 3:22 PM Vasu Dasari wrote:
> Origins for this patch are captured at
> https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048923.html.
>
> Summarizing here, when a test fails, it would be good to pause test
> execution
> and let the developer poke around the system to see current status of
> system.
>
> As part of this patch, made a small tweaks to ovs-macros.at, so that when
> test
> suite fails, ovs_on_exit() function will be called. And in this function,
> a check
> is made to see if an environment variable to OVS_PAUSE_TEST is set. If it
> is
> set, then test suite is paused and will continue to wait for user input
> Ctrl-D. Meanwhile user can poke around the system to see why test case has
> failed. Once done with investigation, user can press ctrl-d to cleanup the
> test suite.
>
> For example, to re-run test case 139:
>
> export OVS_PAUSE_TEST=1
> cd tests/system-userspace-testsuite.dir/139
> sudo -E ./run
>
> When error occurs, above command would display something like this:
> =
> Set environment variable to use various ovs utilities
> export
> OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
> Press ctrl-d to continue:
>
> =
> And from another window, one can execute ovs-xxx commands like:
> export
> OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
> $ ovs-ofctl dump-ports br0
> .
> .
>
> To be able to pause while performing `make check`, one can do:
> $ OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v'
>
> Signed-off-by: Vasu Dasari
> Reviewed-by: Ben Pfaff
> ---
> v0 -> v1:
> Discussion at:
> https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360589.html
> 1. Incorporated review commanets from Ben.
> 2. Changed topics/testing.rst to document this trick
> 3. Made this trick work via "make check" as well, by issuing command:
> "OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v'"
>
> ---
> Documentation/topics/testing.rst | 6 ++
> tests/ovs-macros.at | 24 +++-
> 2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/topics/testing.rst
> b/Documentation/topics/testing.rst
> index a8892e1c1..058b3986f 100644
> --- a/Documentation/topics/testing.rst
> +++ b/Documentation/topics/testing.rst
> @@ -74,6 +74,12 @@ To run tests matching a keyword, e.g. ``ovsdb``, run::
>
> $ make check TESTSUITEFLAGS='-k ovsdb'
>
> +To pause at a failing test (e.g. ``ovsdb``) and inspect the system in
> failed
> +state, follow the instructions given out by issuing following command to
> use
> +various ovs-* utilities::
> +
> +$ OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v -k ovsdb'
> +
> To see a complete list of test options, run::
>
> $ make check TESTSUITEFLAGS=--help
> diff --git a/tests/ovs-macros.at b/tests/ovs-macros.at
> index 10593429d..e58b0a1a0 100644
> --- a/tests/ovs-macros.at
> +++ b/tests/ovs-macros.at
> @@ -35,11 +35,33 @@ m4_divert_push([PREPARE_TESTS])
> # directory.
> ovs_init() {
> ovs_base=`pwd`
> -trap '. "$ovs_base/cleanup"' 0
> +trap ovs_on_exit 0
> : > cleanup
> ovs_setenv
> }
>
> +# Catch testsuite error condition and cleanup test environment by tearing
> down
> +# all interfaces and processes spawned.
> +# User has an option to leave the test environment in error state so that
> system
> +# can be poked around to get more information. User can enable this
> option by setting
> +# environment variable OVS_PAUSE_TEST=1. User needs to press CTRL-D to
> resume the
> +# cleanup operation.
> +ovs_pause() {
> +$as_echo "="
> +$as_echo "Set following environment variable to use various ovs
> utilities"
> +$as_echo "export OVS_RUNDIR=$ovs_base"
> +$as_echo "Press ENTER to continue: "
> +read
> +}
> +
> +ovs_on_exit () {
> +if [ ! -z "${OVS_PAUSE_TEST}" ] && [ -z $at_verbose ]; then
> +trap '' INT
> +ovs_pause
> +fi
> +. "$ovs_base/cleanup"
> +}
> +
> # With no parameter or an empty parameter, sets the OVS_*DIR
> # environment variables to point to $ovs_base, the base directory in
> # which the test is running.
> --
> 2.17.2 (Apple Git-113)
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] ovs-macros: An option to suspend test execution on error
Origins for this patch are captured at
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048923.html.
Summarizing here, when a test fails, it would be good to pause test execution
and let the developer poke around the system to see current status of system.
As part of this patch, made a small tweaks to ovs-macros.at, so that when test
suite fails, ovs_on_exit() function will be called. And in this function, a
check
is made to see if an environment variable to OVS_PAUSE_TEST is set. If it is
set, then test suite is paused and will continue to wait for user input
Ctrl-D. Meanwhile user can poke around the system to see why test case has
failed. Once done with investigation, user can press ctrl-d to cleanup the
test suite.
For example, to re-run test case 139:
export OVS_PAUSE_TEST=1
cd tests/system-userspace-testsuite.dir/139
sudo -E ./run
When error occurs, above command would display something like this:
=
Set environment variable to use various ovs utilities
export
OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
Press ctrl-d to continue:
=
And from another window, one can execute ovs-xxx commands like:
export
OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
$ ovs-ofctl dump-ports br0
.
.
To be able to pause while performing `make check`, one can do:
$ OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v'
Signed-off-by: Vasu Dasari
Reviewed-by: Ben Pfaff
---
v0 -> v1:
Discussion at:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360589.html
1. Incorporated review commanets from Ben.
2. Changed topics/testing.rst to document this trick
3. Made this trick work via "make check" as well, by issuing command:
"OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v'"
---
Documentation/topics/testing.rst | 6 ++
tests/ovs-macros.at | 24 +++-
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/Documentation/topics/testing.rst b/Documentation/topics/testing.rst
index a8892e1c1..058b3986f 100644
--- a/Documentation/topics/testing.rst
+++ b/Documentation/topics/testing.rst
@@ -74,6 +74,12 @@ To run tests matching a keyword, e.g. ``ovsdb``, run::
$ make check TESTSUITEFLAGS='-k ovsdb'
+To pause at a failing test (e.g. ``ovsdb``) and inspect the system in failed
+state, follow the instructions given out by issuing following command to use
+various ovs-* utilities::
+
+$ OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v -k ovsdb'
+
To see a complete list of test options, run::
$ make check TESTSUITEFLAGS=--help
diff --git a/tests/ovs-macros.at b/tests/ovs-macros.at
index 10593429d..e58b0a1a0 100644
--- a/tests/ovs-macros.at
+++ b/tests/ovs-macros.at
@@ -35,11 +35,33 @@ m4_divert_push([PREPARE_TESTS])
# directory.
ovs_init() {
ovs_base=`pwd`
-trap '. "$ovs_base/cleanup"' 0
+trap ovs_on_exit 0
: > cleanup
ovs_setenv
}
+# Catch testsuite error condition and cleanup test environment by tearing down
+# all interfaces and processes spawned.
+# User has an option to leave the test environment in error state so that
system
+# can be poked around to get more information. User can enable this option by
setting
+# environment variable OVS_PAUSE_TEST=1. User needs to press CTRL-D to resume
the
+# cleanup operation.
+ovs_pause() {
+$as_echo "="
+$as_echo "Set following environment variable to use various ovs utilities"
+$as_echo "export OVS_RUNDIR=$ovs_base"
+$as_echo "Press ENTER to continue: "
+read
+}
+
+ovs_on_exit () {
+if [ ! -z "${OVS_PAUSE_TEST}" ] && [ -z $at_verbose ]; then
+trap '' INT
+ovs_pause
+fi
+. "$ovs_base/cleanup"
+}
+
# With no parameter or an empty parameter, sets the OVS_*DIR
# environment variables to point to $ovs_base, the base directory in
# which the test is running.
--
2.17.2 (Apple Git-113)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovs-macros: An option to suspend test execution on error
Sure. Will do. *Vasu Dasari* On Fri, Jul 12, 2019 at 12:08 PM Ben Pfaff wrote: > On Fri, Jul 12, 2019 at 08:42:51AM -0700, Ben Pfaff wrote: > > On Thu, Jul 11, 2019 at 11:46:04AM -0400, Vasu Dasari wrote: > > > Origins for this patch are captured at > > > > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048923.html. > > > > > > Summarizing here, when a test fails, it would be good to pause test > execution > > > and let the developer poke around the system to see current status of > system. > > > > > > As part of this patch, made a small tweaks to ovs-macros.at, so that > when test > > > suite fails, ovs_on_exit() function will be called. And in this > function, a check > > > is made to see if an environment variable to OVS_PAUSE_TEST is set. If > it is > > > set, then test suite is paused and will continue to wait for user input > > > Ctrl-D. Meanwhile user can poke around the system to see why test case > has > > > failed. Once done with investigation, user can press ctrl-d to cleanup > the > > > test suite. > > > > > > For example, to re-run test case 139: > > > > > > export OVS_PAUSE_TEST=1 > > > cd tests/system-userspace-testsuite.dir/139 > > > sudo -E ./run > > > > Seems like a reasonable idea. > > > > The following replies on GNU extensions to "read" and to "printf". I'd > > just substitute a plain "read", so that the user can just push Enter to > > continue. > > Oh, also I'd add a note about this feature to > Documentation/topics/testing.rst. > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovs-macros: An option to suspend test execution on error
Thanks. Will do. *Vasu Dasari* On Fri, Jul 12, 2019 at 11:43 AM Ben Pfaff wrote: > On Thu, Jul 11, 2019 at 11:46:04AM -0400, Vasu Dasari wrote: > > Origins for this patch are captured at > > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048923.html > . > > > > Summarizing here, when a test fails, it would be good to pause test > execution > > and let the developer poke around the system to see current status of > system. > > > > As part of this patch, made a small tweaks to ovs-macros.at, so that > when test > > suite fails, ovs_on_exit() function will be called. And in this > function, a check > > is made to see if an environment variable to OVS_PAUSE_TEST is set. If > it is > > set, then test suite is paused and will continue to wait for user input > > Ctrl-D. Meanwhile user can poke around the system to see why test case > has > > failed. Once done with investigation, user can press ctrl-d to cleanup > the > > test suite. > > > > For example, to re-run test case 139: > > > > export OVS_PAUSE_TEST=1 > > cd tests/system-userspace-testsuite.dir/139 > > sudo -E ./run > > Seems like a reasonable idea. > > The following replies on GNU extensions to "read" and to "printf". I'd > just substitute a plain "read", so that the user can just push Enter to > continue. > > > +while read -s -n 1 key; do > > +printf -v keycode "%d" "'$key" > > +[ $keycode -ne 4 ] || break > > +done > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] ovs-macros: An option to suspend test execution on error
Origins for this patch are captured at
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048923.html.
Summarizing here, when a test fails, it would be good to pause test execution
and let the developer poke around the system to see current status of system.
As part of this patch, made a small tweaks to ovs-macros.at, so that when test
suite fails, ovs_on_exit() function will be called. And in this function, a
check
is made to see if an environment variable to OVS_PAUSE_TEST is set. If it is
set, then test suite is paused and will continue to wait for user input
Ctrl-D. Meanwhile user can poke around the system to see why test case has
failed. Once done with investigation, user can press ctrl-d to cleanup the
test suite.
For example, to re-run test case 139:
export OVS_PAUSE_TEST=1
cd tests/system-userspace-testsuite.dir/139
sudo -E ./run
When error occurs, above command would display something like this:
=
Set environment variable to use various ovs utilities
export
OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
Press ctrl-d to continue:
=
And from another window, one can execute ovs-xxx commands like:
export
OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
$ ovs-ofctl dump-ports br0
.
.
Signed-off-by: Vasu Dasari
---
tests/ovs-macros.at | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/tests/ovs-macros.at b/tests/ovs-macros.at
index 10593429d..57617a410 100644
--- a/tests/ovs-macros.at
+++ b/tests/ovs-macros.at
@@ -35,11 +35,36 @@ m4_divert_push([PREPARE_TESTS])
# directory.
ovs_init() {
ovs_base=`pwd`
-trap '. "$ovs_base/cleanup"' 0
+trap ovs_on_exit 0
: > cleanup
ovs_setenv
}
+# Catch testsuite error condition and cleanup test environment by tearing down
+# all interfaces and processes spawned.
+# User has an option to leave the test environment in error state so that
system
+# can be poked around to get more information. User can enable this option by
setting
+# environment variable OVS_PAUSE_TEST=1. User needs to press CTRL-D to resume
the
+# cleanup operation.
+ovs_pause() {
+echo "="
+echo "Set environment variable to use various ovs utilities"
+echo "export OVS_RUNDIR=$ovs_base"
+echo "Press ctrl-d to continue:"
+while read -s -n 1 key; do
+printf -v keycode "%d" "'$key"
+[ $keycode -ne 4 ] || break
+done
+}
+
+ovs_on_exit () {
+if [ ! -z "${OVS_PAUSE_TEST}" ]; then
+trap '' INT
+ovs_pause
+fi
+. "$ovs_base/cleanup"
+}
+
# With no parameter or an empty parameter, sets the OVS_*DIR
# environment variables to point to $ovs_base, the base directory in
# which the test is running.
--
2.17.2 (Apple Git-113)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v3] tnl-neigh-cache: Purge learnt neighbors when port/bridge is deleted
Say an ARP entry is learnt on a OVS port and when such a port is deleted,
learnt entry should be removed from the port. It would have be aged out after
ARP ageout time. This code will clean up immediately.
Added test case(tunnel - neighbor entry add and deletion) in tunnel.at, to
verify neighbors are added and removed on deletion of a ports and bridges.
Discussion for this addition is at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048754.html
Signed-off-by: Vasu Dasari
Acked-by: Flavio Fernandes
Acked-by: Ben Pfaff
---
v1 -> v2:
Incorporate robot comments. Verified the commit with utilities/checkpatch.py
-1
v2 -> v3:
Incorporate review comments from Flavio and Ben. Discussions at:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360318.html
https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360424.html
---
lib/tnl-neigh-cache.c| 20 +++
lib/tnl-neigh-cache.h| 1 +
ofproto/ofproto-dpif-xlate.c | 3 +++
tests/tunnel.at | 47
4 files changed, 71 insertions(+)
diff --git a/lib/tnl-neigh-cache.c b/lib/tnl-neigh-cache.c
index b28f9f1bb..5bda4af7e 100644
--- a/lib/tnl-neigh-cache.c
+++ b/lib/tnl-neigh-cache.c
@@ -220,6 +220,26 @@ tnl_neigh_cache_run(void)
}
}
+void
+tnl_neigh_flush(const char br_name[IFNAMSIZ])
+{
+struct tnl_neigh_entry *neigh;
+bool changed = false;
+
+ovs_mutex_lock();
+CMAP_FOR_EACH (neigh, cmap_node, ) {
+if (!strcmp(neigh->br_name, br_name)) {
+tnl_neigh_delete(neigh);
+changed = true;
+}
+}
+ovs_mutex_unlock();
+
+if (changed) {
+seq_change(tnl_conf_seq);
+}
+}
+
static void
tnl_neigh_cache_flush(struct unixctl_conn *conn, int argc OVS_UNUSED,
const char *argv[] OVS_UNUSED, void *aux OVS_UNUSED)
diff --git a/lib/tnl-neigh-cache.h b/lib/tnl-neigh-cache.h
index fee8e6a6f..ded9c2f86 100644
--- a/lib/tnl-neigh-cache.h
+++ b/lib/tnl-neigh-cache.h
@@ -37,5 +37,6 @@ int tnl_neigh_lookup(const char dev_name[], const struct
in6_addr *dst,
struct eth_addr *mac);
void tnl_neigh_cache_init(void);
void tnl_neigh_cache_run(void);
+void tnl_neigh_flush(const char dev_name[]);
#endif
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 73966a4e8..28a7fdd84 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -1481,6 +1481,9 @@ xlate_ofport_remove(struct ofport_dpif *ofport)
ovs_assert(new_xcfg);
xport = xport_lookup(new_xcfg, ofport);
+if (xport) {
+tnl_neigh_flush(netdev_get_name(xport->netdev));
+}
xlate_xport_remove(new_xcfg, xport);
}
diff --git a/tests/tunnel.at b/tests/tunnel.at
index 035c54f67..fc6f87936 100644
--- a/tests/tunnel.at
+++ b/tests/tunnel.at
@@ -920,3 +920,50 @@ dnl which is not correct
OVS_VSWITCHD_STOP
AT_CLEANUP
+
+AT_SETUP([tunnel - neighbor entry add and deletion])
+OVS_VSWITCHD_START([add-port br0 p1 -- set Interface p1 type=gre \
+options:remote_ip=1.1.1.1 options:local_ip=2.2.2.2 \
+options:key=5 ofport_request=1 \
+-- add-port br0 p2 -- set Interface p2 type=gre \
+options:local_ip=3.3.3.3 options:remote_ip=4.4.4.4 \
+ofport_request=2])
+AT_CHECK([ovs-vsctl add-br br1 -- set bridge br1 datapath_type=dummy], [0])
+
+dnl Populate tunnel neighbor cache table
+AT_CHECK([
+ovs-appctl tnl/arp/set p1 10.0.0.1 00:00:10:00:00:01
+ovs-appctl tnl/arp/set p1 10.0.0.2 00:00:10:00:00:02
+ovs-appctl tnl/arp/set p2 10.0.1.1 00:00:10:00:01:01
+ovs-appctl tnl/arp/set br0 10.0.2.1 00:00:10:00:02:01
+ovs-appctl tnl/arp/set br0 10.0.2.2 00:00:10:00:02:02
+ovs-appctl tnl/arp/set br1 20.0.0.1 00:00:20:00:00:01
+], [0], [stdout])
+
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | sort], [0], [dnl
+10.0.0.1 00:00:10:00:00:01 p1
+10.0.0.2 00:00:10:00:00:02 p1
+10.0.1.1 00:00:10:00:01:01 p2
+10.0.2.1 00:00:10:00:02:01 br0
+10.0.2.2 00:00:10:00:02:02 br0
+20.0.0.1 00:00:20:00:00:01 br1
+])
+
+dnl neighbor table after deleting port p1
+AT_CHECK([ovs-vsctl del-port br0 p1],[0], [stdout])
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | grep -w p1 | sort], [0], [dnl
+])
+
+dnl neighbor table after deleting bridge br0
+AT_CHECK([ovs-vsctl del-br br0],[0], [stdout])
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | sort], [0], [dnl
+20.0.0.1 00:00:20:00:00:01 br1
+])
+
+dnl neighbor table after deleting bridge br1
+AT_CHECK([ovs-vsctl del-br br1],[0], [stdout])
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | sort], [0], [dnl
+])
+
+OVS_V
Re: [ovs-dev] [PATCH] tnl-neigh-cache: Purge learnt neighbors when port/bridge is deleted
My comments inline: On Mon, Jul 8, 2019 at 9:41 AM Flavio Leitner wrote: > On Tue, Jul 02, 2019 at 08:50:16PM -0400, Vasu Dasari wrote: > > Hi Flavio, > > > > I am trying to emulate the test case scenario you mentioned earlier, > where > > in we need to clean you neighbor cache when an external interface goes > > down. To study that, I wrote a small script based off of test case > > system-traffic.at, "datapath - ping over vxlan tunnel". And this > experiment > > gave me good experience around the understanding of netdev and kmod > > implementation of VxLAN. > > > > Various tests I have performed using the new script include, > > 1. ovs-vswitchd started normally, for performing kernel mode VxLAN tests. > > And in this mode, tested following cases > >a. VxLAN interface being part of OVS. > >b. VxLAN interface external to OVS > >I see that in kernel mode of operation, native tunneling is off, and > > hence no ARP entries are learnt in tnl-neigh-cache. Please refer to > > ofproto-dpif-xlate.c:terminate_native_tunnel(). So, whatever changes we > are > > making here(as part of my commit) are not effected in kernel mode of > > operation. > > In either case my understanding is that OvS doesn't care about the > VXLAN and just hands off the packet to the interface. In another > words, it's the interface's job to encapsulate the traffic and > that's why it doesn't impact on the tnl-neigh-cache. > > Agree. > > > 2. ovs-vswitchd started with "--disable-system" option for performing > > usermode VxLAN tests. And in this mode, tested following cases > >a. VxLAN interface being part of OVS. This test case works. In this > > case, entries are cleanly removed by user deleting the ports from the > > bridge. > > Right, this is the scenario you tested first, if I recall correctly. > > Yes. > >b. VxLAN interface external to OVS. I could not get this case to work. > > I think OvS will inject the packet to the VXLAN interface, but I > never tried this as it seems unusual scenario to have. > > Agree. > > 3. ovs-vswitchd started normally(without --disable-system option) for > > performing usermode VxLAN tests. And in this mode, tested following cases > >a. VxLAN interface being part of OVS. This test case works. In this > > case, entries are cleanly removed by user deleting the ports from the > > bridge. > >b. VxLAN interface external to OVS. I could not get this case to work. > > This looks like a perfect copy from item #2 which is okay, just checking > if there was no copy error somewhere :-) > > This case is different from case 2, where in ovs-vswitchd is started without disable-system option. In this mode, ovs-router learns route from kernel. > > > I could not 2b and 3b use cases to at all. Do you expect these to work > > normally? The reason I ask this is, as I understand from the code, even > > though "ovs/route/show" shows the route to remote vtep, OVS does not know > > which ODP port to take to send the packet out of. Please refer to > > ofproto-dpif-xlate.c:native_tunnel_output() and tnl_route_lookup_flow() > and > > hence packet transmission fails with "native tunnel routing failed". > > > > If you agree that 2b and 3b are not supported use cases, then I can > submit > > my code changes as per your review comments. > > Let me step back a bit because in the scenario I told initially had > the egress device (ethX) with the endpoint address outside of the > bridge while the VXLAN interface was always part of the bridge. > Therefore we had two scenarios to cover with the difference being > the endpoint address being part or not part of the OvS bridge. > > However, looking more closely to the code if the VXLAN is part of the > bridge in userspace, then native tunnel will need the tnl-neigh-cache > to build the headers. Then it sends out the ARP Request packet to the > datapath only, so it doesn't seem to support endpoint addresses outside > of the OvS. I guess your initial patch covering only interfaces as part > of OvS was good enough then. > > Do you agree with that? > Agree. Will send a patch with yours and Ben's comments. Thanks for the review. -Vasu > Thanks! > fbl > > > > > > Please let me know what you think of. > > -Vasu > > > > *Vasu Dasari* > > > > > > On Mon, Jun 24, 2019 at 6:15 PM Flavio Leitner wrote: > > > > > On Mon, Jun 24, 2019 at 05:43:26PM -0400, Vasu Dasari wrote: > > > > On Mon, Jun 24, 2019 at 3:58 PM Flavio Leitner > wrote: > > > > > On Wed, Jun 1
Re: [ovs-dev] [PATCH] tnl-neigh-cache: Purge learnt neighbors when port/bridge is deleted
Hi Flavio,
I am trying to emulate the test case scenario you mentioned earlier, where
in we need to clean you neighbor cache when an external interface goes
down. To study that, I wrote a small script based off of test case
system-traffic.at, "datapath - ping over vxlan tunnel". And this experiment
gave me good experience around the understanding of netdev and kmod
implementation of VxLAN.
Various tests I have performed using the new script include,
1. ovs-vswitchd started normally, for performing kernel mode VxLAN tests.
And in this mode, tested following cases
a. VxLAN interface being part of OVS.
b. VxLAN interface external to OVS
I see that in kernel mode of operation, native tunneling is off, and
hence no ARP entries are learnt in tnl-neigh-cache. Please refer to
ofproto-dpif-xlate.c:terminate_native_tunnel(). So, whatever changes we are
making here(as part of my commit) are not effected in kernel mode of
operation.
2. ovs-vswitchd started with "--disable-system" option for performing
usermode VxLAN tests. And in this mode, tested following cases
a. VxLAN interface being part of OVS. This test case works. In this
case, entries are cleanly removed by user deleting the ports from the
bridge.
b. VxLAN interface external to OVS. I could not get this case to work.
3. ovs-vswitchd started normally(without --disable-system option) for
performing usermode VxLAN tests. And in this mode, tested following cases
a. VxLAN interface being part of OVS. This test case works. In this
case, entries are cleanly removed by user deleting the ports from the
bridge.
b. VxLAN interface external to OVS. I could not get this case to work.
I could not 2b and 3b use cases to at all. Do you expect these to work
normally? The reason I ask this is, as I understand from the code, even
though "ovs/route/show" shows the route to remote vtep, OVS does not know
which ODP port to take to send the packet out of. Please refer to
ofproto-dpif-xlate.c:native_tunnel_output() and tnl_route_lookup_flow() and
hence packet transmission fails with "native tunnel routing failed".
If you agree that 2b and 3b are not supported use cases, then I can submit
my code changes as per your review comments.
Please let me know what you think of.
-Vasu
*Vasu Dasari*
On Mon, Jun 24, 2019 at 6:15 PM Flavio Leitner wrote:
> On Mon, Jun 24, 2019 at 05:43:26PM -0400, Vasu Dasari wrote:
> > On Mon, Jun 24, 2019 at 3:58 PM Flavio Leitner wrote:
> > > On Wed, Jun 19, 2019 at 11:02:07PM -0400, Vasu Dasari wrote:
> > > > +{
> > > > +struct tnl_neigh_entry *neigh;
> > > > +bool changed = false;
> > > > +
> > > > +ovs_mutex_lock();
> > > > +CMAP_FOR_EACH(neigh, cmap_node, ) {
> > > > +if (nullable_string_is_equal(neigh->br_name, br_name)) {
> > > > +tnl_neigh_delete(neigh);
> > > > +changed = true;
> > >
> > > Do you expect to match on additional entries? Otherwise it
> > > could bail out here.
> > >
> > >
> > Say there are two or more neighbors on the port or on bridge, then by
> > bailing out we would be missing others. So, will leave it there.
>
> You're right.
>
> [...]
> > > However, as I mentioned in the discussion, the tnl IP address could
> > > be on a device that doesn't belong to OVS at all. For example:
> [...]
> > > The tnl endpoint must have a valid route, so I suggest to hook the
> > > tnl_neigh_cache_flush into route-table.c which receives a notification
> > > when a route changes. If a route is deleted, we should flush the
> > > device's tnl cache. Doing so, would cover both userspace and kernel
> > > datapath for OVS and non-OVS devices.
> > >
> > >
> > I see what you are saying. Let me play with code a bit and resubmit
> patch.
>
> OK, looking forward to it!
> Thanks Vasu,
> fbl
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] tnl-neigh-cache: Purge learnt neighbors when port/bridge is deleted
Thanks Flavio for your inputs.
My comments inline:
*Vasu Dasari*
On Mon, Jun 24, 2019 at 3:58 PM Flavio Leitner wrote:
> On Wed, Jun 19, 2019 at 11:02:07PM -0400, Vasu Dasari wrote:
> > Say an ARP entry is learnt on a OVS port and when such a port is deleted,
> > learnt entry should be removed from the port. It would have be aged out
> after
> > ARP ageout time. This code will clean up immediately.
> >
> > Added test case(tunnel - neighbor entry add and deletion) in tunnel.at,
> to
> > verify neighbors are added and removed on deletion of a ports and
> bridges.
> >
> > Discussion for this addition is at:
> > https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048754.html
> >
> > Signed-off-by: Vasu Dasari
> > ---
> > lib/tnl-neigh-cache.c| 20 +
> > lib/tnl-neigh-cache.h| 1 +
> > ofproto/ofproto-dpif-xlate.c | 3 +++
> > tests/tunnel.at | 43
> > 4 files changed, 67 insertions(+)
> >
> > diff --git a/lib/tnl-neigh-cache.c b/lib/tnl-neigh-cache.c
> > index b28f9f1bb..8718405db 100644
> > --- a/lib/tnl-neigh-cache.c
> > +++ b/lib/tnl-neigh-cache.c
> > @@ -220,6 +220,26 @@ tnl_neigh_cache_run(void)
> > }
> > }
> >
> > +void
> > +tnl_neigh_flush(const char br_name[])
>
> It seems the file uses a convention declaring using IFNAMSIZ
>
Sure. I did not notice that. Will fix this.
>
> > +{
> > +struct tnl_neigh_entry *neigh;
> > +bool changed = false;
> > +
> > +ovs_mutex_lock();
> > +CMAP_FOR_EACH(neigh, cmap_node, ) {
> > +if (nullable_string_is_equal(neigh->br_name, br_name)) {
> > +tnl_neigh_delete(neigh);
> > +changed = true;
>
> Do you expect to match on additional entries? Otherwise it
> could bail out here.
>
>
Say there are two or more neighbors on the port or on bridge, then by
bailing out we would be missing others. So, will leave it there.
>
> > +}
> > +}
> > +ovs_mutex_unlock();
> > +
> > +if (changed) {
> > +seq_change(tnl_conf_seq);
> > +}
> > +}
> > +
> > static void
> > tnl_neigh_cache_flush(struct unixctl_conn *conn, int argc OVS_UNUSED,
> > const char *argv[] OVS_UNUSED, void *aux OVS_UNUSED)
> > diff --git a/lib/tnl-neigh-cache.h b/lib/tnl-neigh-cache.h
> > index fee8e6a6f..ded9c2f86 100644
> > --- a/lib/tnl-neigh-cache.h
> > +++ b/lib/tnl-neigh-cache.h
> > @@ -37,5 +37,6 @@ int tnl_neigh_lookup(const char dev_name[], const
> struct in6_addr *dst,
> > struct eth_addr *mac);
> > void tnl_neigh_cache_init(void);
> > void tnl_neigh_cache_run(void);
> > +void tnl_neigh_flush(const char dev_name[]);
> >
> > #endif
> > diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
> > index 73966a4e8..e0cd8edab 100644
> > --- a/ofproto/ofproto-dpif-xlate.c
> > +++ b/ofproto/ofproto-dpif-xlate.c
> > @@ -1481,6 +1481,9 @@ xlate_ofport_remove(struct ofport_dpif *ofport)
> > ovs_assert(new_xcfg);
> >
> > xport = xport_lookup(new_xcfg, ofport);
> > +if(xport) {
> ^--- space needed here.
>
> > +tnl_neigh_flush(netdev_get_name(xport->netdev));
> > +}
> > xlate_xport_remove(new_xcfg, xport);
>
>
> Shouldn't this be in xlate_xport_remove()?
>
>
My first attempt was to put the hook in xlate_xport_remove(). But, this
function is also getting called from another code path as well
xlate_txn_commit() which is getting called as part of type_run() callback
for ofproto_class.
type_run()(from ofproto-dpif.c)
xlate_txn_commit()
xlate_xcfg_free()
xlate_xbridge_remove()
xlate_xport_remove()
>From documentation this function can be called from periodically and hence
flushing ARP entries. So, chose to do the flush when a ofport is removed.
However, as I mentioned in the discussion, the tnl IP address could
> be on a device that doesn't belong to OVS at all. For example:
>
> br-tun
>|
>+- vxlan0 --- remote-ipaddr=192.168.1.10
>|
>+- vxlan1 --- remote-ipaddr=192.168.2.10
>
> And then you have:
>eth0 --- 192.168.1.1/24
>
>eth1 --- 192.168.2.1/24
>
> In this case, if we took either eth0 or eth1 down, the cache is not
> immediately flushed.
>
> The tnl endpoint must have a valid route, so I suggest to hook the
> tnl_neigh_cache_flush into route-table.c which receives a notification
> when a route changes. If a rou
[ovs-dev] [PATCH v2] tnl-neigh-cache: Purge learnt neighbors when port/bridge is deleted
Say an ARP entry is learnt on a OVS port and when such a port is deleted,
learnt entry should be removed from the port. It would have be aged out after
ARP ageout time. This code will clean up immediately.
Added test case(tunnel - neighbor entry add and deletion) in tunnel.at, to
verify neighbors are added and removed on deletion of a ports and bridges.
Discussion for this addition is at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048754.html
Signed-off-by: Vasu Dasari
---
v1 -> v2:
Incorporate robot comments. Verified the commit with utilities/checkpatch.py
-1
---
lib/tnl-neigh-cache.c| 20 +
lib/tnl-neigh-cache.h| 1 +
ofproto/ofproto-dpif-xlate.c | 3 +++
tests/tunnel.at | 43
4 files changed, 67 insertions(+)
diff --git a/lib/tnl-neigh-cache.c b/lib/tnl-neigh-cache.c
index b28f9f1bb..daa54432a 100644
--- a/lib/tnl-neigh-cache.c
+++ b/lib/tnl-neigh-cache.c
@@ -220,6 +220,26 @@ tnl_neigh_cache_run(void)
}
}
+void
+tnl_neigh_flush(const char br_name[])
+{
+struct tnl_neigh_entry *neigh;
+bool changed = false;
+
+ovs_mutex_lock();
+CMAP_FOR_EACH (neigh, cmap_node, ) {
+if (nullable_string_is_equal(neigh->br_name, br_name)) {
+tnl_neigh_delete(neigh);
+changed = true;
+}
+}
+ovs_mutex_unlock();
+
+if (changed) {
+seq_change(tnl_conf_seq);
+}
+}
+
static void
tnl_neigh_cache_flush(struct unixctl_conn *conn, int argc OVS_UNUSED,
const char *argv[] OVS_UNUSED, void *aux OVS_UNUSED)
diff --git a/lib/tnl-neigh-cache.h b/lib/tnl-neigh-cache.h
index fee8e6a6f..ded9c2f86 100644
--- a/lib/tnl-neigh-cache.h
+++ b/lib/tnl-neigh-cache.h
@@ -37,5 +37,6 @@ int tnl_neigh_lookup(const char dev_name[], const struct
in6_addr *dst,
struct eth_addr *mac);
void tnl_neigh_cache_init(void);
void tnl_neigh_cache_run(void);
+void tnl_neigh_flush(const char dev_name[]);
#endif
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 73966a4e8..28a7fdd84 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -1481,6 +1481,9 @@ xlate_ofport_remove(struct ofport_dpif *ofport)
ovs_assert(new_xcfg);
xport = xport_lookup(new_xcfg, ofport);
+if (xport) {
+tnl_neigh_flush(netdev_get_name(xport->netdev));
+}
xlate_xport_remove(new_xcfg, xport);
}
diff --git a/tests/tunnel.at b/tests/tunnel.at
index 035c54f67..6d7550724 100644
--- a/tests/tunnel.at
+++ b/tests/tunnel.at
@@ -920,3 +920,46 @@ dnl which is not correct
OVS_VSWITCHD_STOP
AT_CLEANUP
+
+AT_SETUP([tunnel - neighbor entry add and deletion])
+OVS_VSWITCHD_START([add-port br0 p1 -- set Interface p1 type=gre \
+options:remote_ip=1.1.1.1 options:local_ip=2.2.2.2 \
+options:key=5 ofport_request=1 \
+-- add-port br0 p2 -- set Interface p2 type=gre \
+options:local_ip=3.3.3.3 options:remote_ip=4.4.4.4 \
+ofport_request=2])
+AT_CHECK([ovs-vsctl add-br br1 -- set bridge br1 datapath_type=dummy], [0])
+
+dnl Populate tunnel neighbor cache table
+AT_CHECK([
+ovs-appctl tnl/arp/set p1 10.0.0.1 00:00:10:00:00:01
+ovs-appctl tnl/arp/set p2 10.0.1.1 00:00:10:00:01:01
+ovs-appctl tnl/arp/set br0 10.0.2.1 00:00:10:00:02:01
+ovs-appctl tnl/arp/set br1 20.0.0.1 00:00:20:00:00:01
+], [0], [stdout])
+
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | sort], [0], [dnl
+10.0.0.1 00:00:10:00:00:01 p1
+10.0.1.1 00:00:10:00:01:01 p2
+10.0.2.1 00:00:10:00:02:01 br0
+20.0.0.1 00:00:20:00:00:01 br1
+])
+
+dnl neighbor table after deleting port p1
+AT_CHECK([ovs-vsctl del-port br0 p1],[0], [stdout])
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | grep -w p1 | sort], [0], [dnl
+])
+
+dnl neighbor table after deleting bridge br0
+AT_CHECK([ovs-vsctl del-br br0],[0], [stdout])
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | sort], [0], [dnl
+20.0.0.1 00:00:20:00:00:01 br1
+])
+
+dnl neighbor table after deleting bridge br1
+AT_CHECK([ovs-vsctl del-br br1],[0], [stdout])
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | sort], [0], [dnl
+])
+
+OVS_VSWITCHD_STOP
+AT_CLEANUP
--
2.17.2 (Apple Git-113)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] tnl-neigh-cache: Purge learnt neighbors when port/bridge is deleted
Say an ARP entry is learnt on a OVS port and when such a port is deleted,
learnt entry should be removed from the port. It would have be aged out after
ARP ageout time. This code will clean up immediately.
Added test case(tunnel - neighbor entry add and deletion) in tunnel.at, to
verify neighbors are added and removed on deletion of a ports and bridges.
Discussion for this addition is at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048754.html
Signed-off-by: Vasu Dasari
---
lib/tnl-neigh-cache.c| 20 +
lib/tnl-neigh-cache.h| 1 +
ofproto/ofproto-dpif-xlate.c | 3 +++
tests/tunnel.at | 43
4 files changed, 67 insertions(+)
diff --git a/lib/tnl-neigh-cache.c b/lib/tnl-neigh-cache.c
index b28f9f1bb..8718405db 100644
--- a/lib/tnl-neigh-cache.c
+++ b/lib/tnl-neigh-cache.c
@@ -220,6 +220,26 @@ tnl_neigh_cache_run(void)
}
}
+void
+tnl_neigh_flush(const char br_name[])
+{
+struct tnl_neigh_entry *neigh;
+bool changed = false;
+
+ovs_mutex_lock();
+CMAP_FOR_EACH(neigh, cmap_node, ) {
+if (nullable_string_is_equal(neigh->br_name, br_name)) {
+tnl_neigh_delete(neigh);
+changed = true;
+}
+}
+ovs_mutex_unlock();
+
+if (changed) {
+seq_change(tnl_conf_seq);
+}
+}
+
static void
tnl_neigh_cache_flush(struct unixctl_conn *conn, int argc OVS_UNUSED,
const char *argv[] OVS_UNUSED, void *aux OVS_UNUSED)
diff --git a/lib/tnl-neigh-cache.h b/lib/tnl-neigh-cache.h
index fee8e6a6f..ded9c2f86 100644
--- a/lib/tnl-neigh-cache.h
+++ b/lib/tnl-neigh-cache.h
@@ -37,5 +37,6 @@ int tnl_neigh_lookup(const char dev_name[], const struct
in6_addr *dst,
struct eth_addr *mac);
void tnl_neigh_cache_init(void);
void tnl_neigh_cache_run(void);
+void tnl_neigh_flush(const char dev_name[]);
#endif
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 73966a4e8..e0cd8edab 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -1481,6 +1481,9 @@ xlate_ofport_remove(struct ofport_dpif *ofport)
ovs_assert(new_xcfg);
xport = xport_lookup(new_xcfg, ofport);
+if(xport) {
+tnl_neigh_flush(netdev_get_name(xport->netdev));
+}
xlate_xport_remove(new_xcfg, xport);
}
diff --git a/tests/tunnel.at b/tests/tunnel.at
index 035c54f67..6d7550724 100644
--- a/tests/tunnel.at
+++ b/tests/tunnel.at
@@ -920,3 +920,46 @@ dnl which is not correct
OVS_VSWITCHD_STOP
AT_CLEANUP
+
+AT_SETUP([tunnel - neighbor entry add and deletion])
+OVS_VSWITCHD_START([add-port br0 p1 -- set Interface p1 type=gre \
+options:remote_ip=1.1.1.1 options:local_ip=2.2.2.2 \
+options:key=5 ofport_request=1 \
+-- add-port br0 p2 -- set Interface p2 type=gre \
+options:local_ip=3.3.3.3 options:remote_ip=4.4.4.4 \
+ofport_request=2])
+AT_CHECK([ovs-vsctl add-br br1 -- set bridge br1 datapath_type=dummy], [0])
+
+dnl Populate tunnel neighbor cache table
+AT_CHECK([
+ovs-appctl tnl/arp/set p1 10.0.0.1 00:00:10:00:00:01
+ovs-appctl tnl/arp/set p2 10.0.1.1 00:00:10:00:01:01
+ovs-appctl tnl/arp/set br0 10.0.2.1 00:00:10:00:02:01
+ovs-appctl tnl/arp/set br1 20.0.0.1 00:00:20:00:00:01
+], [0], [stdout])
+
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | sort], [0], [dnl
+10.0.0.1 00:00:10:00:00:01 p1
+10.0.1.1 00:00:10:00:01:01 p2
+10.0.2.1 00:00:10:00:02:01 br0
+20.0.0.1 00:00:20:00:00:01 br1
+])
+
+dnl neighbor table after deleting port p1
+AT_CHECK([ovs-vsctl del-port br0 p1],[0], [stdout])
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | grep -w p1 | sort], [0], [dnl
+])
+
+dnl neighbor table after deleting bridge br0
+AT_CHECK([ovs-vsctl del-br br0],[0], [stdout])
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | sort], [0], [dnl
+20.0.0.1 00:00:20:00:00:01 br1
+])
+
+dnl neighbor table after deleting bridge br1
+AT_CHECK([ovs-vsctl del-br br1],[0], [stdout])
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | sort], [0], [dnl
+])
+
+OVS_VSWITCHD_STOP
+AT_CLEANUP
--
2.17.2 (Apple Git-113)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
