[ovs-dev] [branch 2.10][PATCH] ovn-nbctl: Fix the ovn-nbctl test "LBs - daemon" which fails during rpm build
From: Numan Siddique
When 'make check' is called by the mock rpm build (which disables networking),
the test "ovn-nbctl: LBs - daemon" fails when it runs the command
"ovn-nbctl lb-add lb0 30.0.0.1a 192.168.10.10:80,192.168.10.20:80". ovn-nbctl
extracts the vip by calling the socket util function 'inet_parse_active()',
and this function blocks when libunbound function ub_resolve() is called
further down. ub_resolve() is a blocking function without timeout and all the
ovs/ovn utilities use this function.
As reported by Timothy Redaelli, the issue can also be reproduced by running
the below commands
$ sudo unshare -mn -- sh -c 'ip addr add dev lo 127.0.0.1 && \
mount --bind /dev/null /etc/resolv.conf && runuser $SUDO_USER'
$ make sandbox SANDBOXFLAGS="--ovn"
$ ovn-nbctl -vsocket_util:off lb-add lb0 30.0.0.1a \
192.168.10.10:80,192.168.10.20:80
To address this issue, this patch adds a new bool argument 'resolve_host' to
the function inet_parse_active() to resolve the host only if it is 'true'.
ovn-nbctl/ovn-northd will pass 'false' when it calls this function to parse
the load balancer values.
Reported-by: Timothy Redaelli
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1641672
Signed-off-by: Numan Siddique
(cherry picked from commit f31b8ae7a7a777dd9dc40997903a283409674eae)
Conflicts:
ovn/utilities/ovn-trace.c
---
lib/socket-util.c| 7 ---
lib/socket-util.h| 2 +-
lib/stream.c | 2 +-
ofproto/ofproto-dpif-sflow.c | 2 +-
ovn/northd/ovn-northd.c | 2 +-
ovn/utilities/ovn-nbctl.c| 6 +++---
ovsdb/raft-private.c | 2 +-
7 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/lib/socket-util.c b/lib/socket-util.c
index 504f4cd59..5f82e89c1 100644
--- a/lib/socket-util.c
+++ b/lib/socket-util.c
@@ -518,12 +518,13 @@ exit:
* is optional and defaults to 'default_port' (use 0 to make the kernel choose
* an available port, although this isn't usually appropriate for active
* connections). If 'default_port' is negative, then is required.
+ * It resolves the host if 'resolve_host' is true.
*
* On success, returns true and stores the parsed remote address into '*ss'.
* On failure, logs an error, stores zeros into '*ss', and returns false. */
bool
inet_parse_active(const char *target_, int default_port,
- struct sockaddr_storage *ss)
+ struct sockaddr_storage *ss, bool resolve_host)
{
char *target = xstrdup(target_);
char *port, *host;
@@ -538,7 +539,7 @@ inet_parse_active(const char *target_, int default_port,
ok = false;
} else {
ok = parse_sockaddr_components(ss, host, port, default_port,
- target_, true);
+ target_, resolve_host);
}
if (!ok) {
memset(ss, 0, sizeof *ss);
@@ -575,7 +576,7 @@ inet_open_active(int style, const char *target, int
default_port,
int error;
/* Parse. */
-if (!inet_parse_active(target, default_port, )) {
+if (!inet_parse_active(target, default_port, , true)) {
error = EAFNOSUPPORT;
goto exit;
}
diff --git a/lib/socket-util.h b/lib/socket-util.h
index 6d386304d..a65433d90 100644
--- a/lib/socket-util.h
+++ b/lib/socket-util.h
@@ -49,7 +49,7 @@ ovs_be32 guess_netmask(ovs_be32 ip);
void inet_parse_host_port_tokens(char *s, char **hostp, char **portp);
void inet_parse_port_host_tokens(char *s, char **portp, char **hostp);
bool inet_parse_active(const char *target, int default_port,
- struct sockaddr_storage *ssp);
+ struct sockaddr_storage *ssp, bool resolve_host);
int inet_open_active(int style, const char *target, int default_port,
struct sockaddr_storage *ssp, int *fdp, uint8_t dscp);
diff --git a/lib/stream.c b/lib/stream.c
index 4e15fe0c8..c4dabda39 100644
--- a/lib/stream.c
+++ b/lib/stream.c
@@ -751,7 +751,7 @@ stream_parse_target_with_default_port(const char *target,
int default_port,
struct sockaddr_storage *ss)
{
return ((!strncmp(target, "tcp:", 4) || !strncmp(target, "ssl:", 4))
-&& inet_parse_active(target + 4, default_port, ss));
+&& inet_parse_active(target + 4, default_port, ss, true));
}
/* Attempts to guess the content type of a stream whose first few bytes were
diff --git a/ofproto/ofproto-dpif-sflow.c b/ofproto/ofproto-dpif-sflow.c
index 62a09b5d1..7da31753c 100644
--- a/ofproto/ofproto-dpif-sflow.c
+++ b/ofproto/ofproto-dpif-sflow.c
@@ -468,7 +468,7 @@ sflow_choose_agent_address(const char *agent_device,
const char *target;
SSET_FOR_EACH (target, targets) {
struct sockaddr_storage ss;
-if (inet_parse_active(target, SFL_DEFAULT_COLLECTOR_PORT, )) {
+if (inet_parse_active(target, SFL_DEFAULT_COLLECTOR_PORT, , true)) {
/* sFlow only supports target in default routing
Re: [ovs-dev] [PATCH] dns-resolve: Stop dns resolving when dns servers are configured.
[CCing Alin for his opinion on Windows issue]
On Mon, Nov 05, 2018 at 04:20:18PM -0800, Yifeng Sun wrote:
> DNS resolution should fail if no DNS servers are available. This
> patch fixes it and also enables users to use environment variable
> OVS_RESOLV_CONF to specify the path for DNS server configuration
> file.
>
> Suggested-by: Ben Pfaff
> Suggested-by: Mark Michelson
> Signed-off-by: Yifeng Sun
> ---
> lib/dns-resolve.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/lib/dns-resolve.c b/lib/dns-resolve.c
> index 3c6d70e8fbba..60757cb1eb8a 100644
> --- a/lib/dns-resolve.c
> +++ b/lib/dns-resolve.c
> @@ -83,14 +83,26 @@ dns_resolve_init(bool is_daemon)
> }
>
> #ifdef __linux__
> -const char *filename = "/etc/resolv.conf";
> +const char *filename = getenv("OVS_RESOLV_CONF");
> +if (filename == NULL) {
> +filename = "/etc/resolv.conf";
> +}
> struct stat s;
> if (!stat(filename, ) || errno != ENOENT) {
> int retval = ub_ctx_resolvconf(ub_ctx__, filename);
> if (retval != 0) {
> VLOG_WARN_RL(, "Failed to read %s: %s",
> filename, ub_strerror(retval));
> +ub_ctx_delete(ub_ctx__);
> +ub_ctx__ = NULL;
> +return;
> }
> +} else {
> +VLOG_WARN_RL(, "Failed to read %s: %s",
> + filename, ovs_strerror(errno));
> +ub_ctx_delete(ub_ctx__);
> +ub_ctx__ = NULL;
> +return;
> }
> #endif
Thanks for the improvement. It spurs a few thoughts.
It looks like part of this may be a somewhat independent bug fix
because, previously, ub_ctx__ was not deleted or set to NULL on error.
Is that part of this patch also a bug fix?
This looks a little unfair to Windows. I think that ub_ctx_resolvconf()
works on Windows if you supply a file name, or even if you pass NULL to
use the default Windows resolver parameters.
I think that the overall logic, then, could more fairly to Windows be
something like this:
const char *filename = getenv("OVS_RESOLV_CONF");
if (!filename) {
#ifdef _WIN32
/* On Windows, NULL means to use the system default nameserver. */
#else
filename = "/etc/resolv.conf";
#endif
}
The documentation for ub_ctx_resolvconf() is here:
https://linux.die.net/man/3/ub_ctx_resolvconf
(If we use this implementation, we need to be careful about error
messages, because NULL shouldn't be used for %s.)
The new environment variable should be documented in some appropriate
place.
Thanks a lot!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OvS 2.10 MTU greater than 1518 - not working
Hi Ben/Ilya, Sorry for the delay, we are not able to reproduce this issue :( Thanks for the help. Shahaji On Wed, Oct 17, 2018 at 4:04 PM Shahaji Bhosle wrote: > Thanks Ben/Ilya, > Will give that a shot and update, I had to roll back to 2.9. But will > update. Thanks again and appreciate the quick reply, Shahaji > > On Wed, Oct 17, 2018 at 11:35 AM Ben Pfaff wrote: > >> On Tue, Oct 16, 2018 at 06:46:52PM -0400, Shahaji Bhosle via dev wrote: >> > Just upgraded to 2.10 and running OvS with DPDK , I used to set MTU to >> 1900 >> > to accommodate VxLAN headers in 2.9 but not I cannot send packets bigger >> > than 1518 bytes. Is this a known issue, I have not got chance to check >> the >> > code, but wanted to check if you know anything >> >> Make sure you adjusted the MTU of both bridges involved. The bridge >> with VXLAN ports should have an MTU smaller than the bridge with the >> physical port, by the size of the VXLAN header. >> > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Error at ovsdb-cluster.at:204
Not sure if this is reported before. I am seeing failure (not always) at the following line when running the test ten times in the main branch: i=10;while [ $i -gt 0 ]; do make check TESTSUITEFLAGS='2485' | grep "2485: OVSDB 3-server torture test"; i=$((i-1)); done 2485: OVSDB 3-server torture test - remove/re-add follower 2 FAILED ( ovsdb-cluster.at:204) ERROR: 1 test was run, 1 failed unexpectedly. make[3]: *** [check-local] Error 1 make[2]: *** [check-am] Error 2 make[1]: *** [check-recursive] Error 1 make: *** [check] Error 2 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok In another instance, the test got skipped once: i=10;while [ $i -gt 0 ]; do make check TESTSUITEFLAGS='2485' | grep "2485: OVSDB 3-server torture test"; i=$((i-1)); done 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 skipped ( ovsdb-cluster.at:197) 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok 2485: OVSDB 3-server torture test - remove/re-add follower 2 ok ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] dns-resolve: Stop dns resolving when dns servers are configured.
DNS resolution should fail if no DNS servers are available. This
patch fixes it and also enables users to use environment variable
OVS_RESOLV_CONF to specify the path for DNS server configuration
file.
Suggested-by: Ben Pfaff
Suggested-by: Mark Michelson
Signed-off-by: Yifeng Sun
---
lib/dns-resolve.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/lib/dns-resolve.c b/lib/dns-resolve.c
index 3c6d70e8fbba..60757cb1eb8a 100644
--- a/lib/dns-resolve.c
+++ b/lib/dns-resolve.c
@@ -83,14 +83,26 @@ dns_resolve_init(bool is_daemon)
}
#ifdef __linux__
-const char *filename = "/etc/resolv.conf";
+const char *filename = getenv("OVS_RESOLV_CONF");
+if (filename == NULL) {
+filename = "/etc/resolv.conf";
+}
struct stat s;
if (!stat(filename, ) || errno != ENOENT) {
int retval = ub_ctx_resolvconf(ub_ctx__, filename);
if (retval != 0) {
VLOG_WARN_RL(, "Failed to read %s: %s",
filename, ub_strerror(retval));
+ub_ctx_delete(ub_ctx__);
+ub_ctx__ = NULL;
+return;
}
+} else {
+VLOG_WARN_RL(, "Failed to read %s: %s",
+ filename, ovs_strerror(errno));
+ub_ctx_delete(ub_ctx__);
+ub_ctx__ = NULL;
+return;
}
#endif
--
2.7.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1 3/3] Vlan Support in ovn, northd changes to read logical switch network type.
I don't see where this series actually changes behavior on the hypervisors. Can you help me see it? It's not clear to me that these are really three independent patches. Usually, for example, there is no reason to separate a change to the northbound schema and ovn-nbctl changes to enable use of that change. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1 2/3] Vlan Support in ovn, add nbctl commands to set network type
On Fri, Oct 26, 2018 at 01:39:43AM +, Ankur Sharma wrote: > As a part of proposal for distributed virtual routing > for VLAN networks through OVN, this series has code changes > for Layer 2. > > [1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html > [2] > https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing > > This Series: > a. Changes in OVN NB Schema to introduce a logical switch type. > b. Changes in ovn-nbctl to configure a logical switch type. > c. Changes in ovn-northd to process and save a logical switch type. > > Adding a logical switch type would be helpful in following: > a. Debugging, since VLAN backed logical switch is dependent on >localnet ports, hence basic validations like localnet port >configured or not etc., can be done with ease. > > b. Helps with Layer 3 implementation >(https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353179.html). > > This Patch: > a. By default set network_type as overlay during ls_add handling. > > b. Add a new ovn-nbctl command to set network type of a logical >switch. >ovn-nbctl ls-set-network-type LS_NAME vlan|overlay > > c. Display network type along with logical switch, for example: ># ovn-nbctl ls-list >d94d7531-128b-43a2-bff0-56f2aa2ea878 (bar) (type: overlay) >531e6f24-f6ae-4ea3-856d-ac986f900770 (foo) (type: vlan) > > d. Unit tests to validate this command > > Signed-off-by: Ankur Sharma Usually I'd expect that the network type would be fixed for a given logical network, rather than changing after it is created. Thus, I'd recommend adding an option to ls-add to specify the network type, rather than a new command. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1 1/3] Vlan Support in ovn, add network type in northbound schema
On Fri, Oct 26, 2018 at 01:39:35AM +, Ankur Sharma wrote:
> This Patch:
> a. Add 1 more column to the Logical_Switch table in north bound
>schema, to indicate if a logical switch is of type "vlan" or "overlay".
>We will support NULL value in this table as well, to keep it backward
>compatible. NULL value will be treated as "overlay" type by northd.
The usual way to do that in OVSDB is to allow the column to be empty,
like this:
"network_type": {"type": {"key": {"type": "string",
"enum": ["set", ["overlay", "vlan"]]},
"min": 0,
"max": 1}},
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] [RFC] Add a new OVS action check_pkt_larger
On Mon, Nov 05, 2018 at 09:45:10PM +0530, nusid...@redhat.com wrote: > From: Numan Siddique > > This patch adds a new action 'check_pkt_larger' which checks if the > packet is larger than the given size and stores the result in the > destination register. > > Usage: check_pkt_larger:len->REGISTER > Eg. match=...,actions=check_pkt_larger:1442->NXM_NX_REG0[0],next; > > When translating this action, SLOW_ACTION is set so that datapath > flow is not added. > > This action is intended to be used by OVN to check the packet length > and generate an ICMP packet with type 3, code 4 and next hop mtu > in the logical router pipeline if the MTU of the physical interface > is lesser than the packet length. More information can be found here [1] > > TODO: > - Add test case. > - Change the action format from check_pkt_larger:len to check_pkt_larger(len) > > Request to suggest a better name for the action in case 'check_pkt_larger' > seems odd. > > [1] - https://mail.openvswitch.org/pipermail/ovs-discuss/2018-July/047039.html > > Signed-off-by: Numan Siddique Thanks for working on this. It looks like this patch makes the assumption that every packet goes through userspace, but that isn't true. The action needs to be implemented in the OVS datapaths so that the kernel or userspace can direct oversized packets to the slow path. Thanks, Ben. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH V2] erspan: fix error handling for erspan tunnel
On Mon, Nov 05, 2018 at 11:53:33AM -0800, Gregory Rose wrote:
>
> On 11/5/2018 11:38 AM, Ben Pfaff wrote:
> >On Mon, Nov 05, 2018 at 11:07:17AM -0800, Gregory Rose wrote:
> >>On 11/5/2018 7:52 AM, Ben Pfaff wrote:
> >>>Where can I find this patch? It is not in patchwork, nor in my personal
> >>>email archive.
> >>>
> >>>Thanks,
> >>>
> >>>Ben.
> >>Here:
> >>
> >>From: Haishuang Yan
> >>
> >>Upstream commit:
> >> commit 51dc63e3911fbb1f0a7a32da2fe56253e2040ea4
> >> Author: Haishuang Yan
> >> Date: Mon Sep 10 22:19:48 2018 +0800
> >>
> >> erspan: fix error handling for erspan tunnel
> >>
> >> When processing icmp unreachable message for erspan tunnel, tunnel id
> >> should be erspan_net_id instead of ipgre_net_id.
> >>
> >> Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
> >> Cc: William Tu
> >> Signed-off-by: Haishuang Yan
> >> Acked-by: William Tu
> >> Signed-off-by: David S. Miller
> >>
> >>Fixes: 8e53509c ("gre: introduce native tunnel support for ERSPAN")
> >>Signed-off-by: Greg Rose
> >>---
> >> datapath/linux/compat/ip_gre.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >>diff --git a/datapath/linux/compat/ip_gre.c b/datapath/linux/compat/ip_gre.c
> >>index b7322c5..6ac2dd9 100644
> >>--- a/datapath/linux/compat/ip_gre.c
> >>+++ b/datapath/linux/compat/ip_gre.c
> >>@@ -312,6 +312,9 @@ static int ipgre_rcv(struct sk_buff *skb, const struct
> >>tnl_ptk_info *tpi,
> >>if (tpi->proto == htons(ETH_P_TEB))
> >>itn = net_generic(net, gre_tap_net_id);
> >>+ else if (tpi->proto == htons(ETH_P_ERSPAN) ||
> >>+tpi->proto == htons(ETH_P_ERSPAN2))
> >>+ itn = net_generic(net, erspan_net_id);
> >>else
> >>itn = net_generic(net, ipgre_net_id);
> >Thanks, applied to master.
>
> Thank you! A backport to 2.10 is probably a good idea as well.
Done.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH -v2] checkpatch: fix typographical error
- Original Message -
> From: "Ben Pfaff"
> To: "Bala Sankaran"
> Cc: ovs-dev@openvswitch.org
> Sent: Monday, November 5, 2018 2:45:09 PM
> Subject: Re: [ovs-dev] [PATCH -v2] checkpatch: fix typographical error
>
> On Mon, Nov 05, 2018 at 01:37:32PM -0500, Bala Sankaran wrote:
> > A typographical error in a prompt for missing
> > python enchant library is identified and fixed.
> >
> > v2:
> > * Rebasing done to resolve previous conflicts
> >
> > Signed-off-by: Bala Sankaran
>
> Thanks, applied to master.
>
> In the future please put information about changes from one version to
> another after the ---, so it doesn't end up in the change log.
Sure,
Will keep that in mind.
Thank you.
>
> > ---
> > utilities/checkpatch.py | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/utilities/checkpatch.py b/utilities/checkpatch.py
> > index 8bbda7898..41676adab 100755
> > --- a/utilities/checkpatch.py
> > +++ b/utilities/checkpatch.py
> > @@ -927,7 +927,7 @@ if __name__ == '__main__':
> > checking_file = True
> > elif o in ("-S", "--spellcheck-comments"):
> > if not open_spell_check_dict():
> > -print("WARNING: The enchant library isn't availble.")
> > +print("WARNING: The enchant library isn't available.")
> > print(" Please install python enchant.")
> > else:
> > spellcheck_comments = True
> > --
> > 2.17.2
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
-
Bala Sankaran
Networking Services Intern
Red Hat Inc .,
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] OVN: introduce mac_prefix support to IPAM
On Mon, Nov 05, 2018 at 06:17:54PM +0100, Lorenzo Bianconi wrote: > > > > Thanks for the patch. > > Hi Ben, > > thx for the review. Few comments inline. > > Regards, > Lorenzo > > > > > I'm not sure in what circumstances a broadcast domain would be shared > > among deployments. I tend to think of OVN L2 networks as contained. > > But I guess this patch was written for a reason, so it must be common > > enough. > > > > I can see at least two possible routes here: > > > > - The current one, in which there is a default MAC_ADDR_PREFIX. Two > > OVN deployments cannot coexist using MACAM, supposing they somehow > > share a broadcast domain, unless at least one of them manually > > selects an alternate MAC prefix. This may be desirable if it is > > important that the default MAC prefix 0A-00-00 be recognizable. > > > > I preferred to maintain a default mac prefix for compatibility with > older deployments > that maybe assume to have a default mac prefix for MACAM, but if you > prefer we can > switch to the second implementation > > > - An alternative would be for every OVN deployment to automatically > > select a random MAC address prefix. When ovn-northd starts, it > > would read the MAC address prefix out of NB_Global, and if there > > isn't one, generate one randomly and store it into NB_Global. > > Then there would be fewer pitfalls in setting up multiple > > deployments. > > > > the only concern that come to my mind is that, is possible to have a > mac prefix collision on multiple > deployments when mac prefix is randomly chosen? Yes, of course, it's a 22-bit space, collisions can happen. It sounds like we should stick with the proposed approach, but I'll give this a little while for others to comment. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH V2] erspan: fix error handling for erspan tunnel
On Mon, Nov 05, 2018 at 11:07:17AM -0800, Gregory Rose wrote:
> On 11/5/2018 7:52 AM, Ben Pfaff wrote:
> >Where can I find this patch? It is not in patchwork, nor in my personal
> >email archive.
> >
> >Thanks,
> >
> >Ben.
>
> Here:
>
> From: Haishuang Yan
>
> Upstream commit:
> commit 51dc63e3911fbb1f0a7a32da2fe56253e2040ea4
> Author: Haishuang Yan
> Date: Mon Sep 10 22:19:48 2018 +0800
>
> erspan: fix error handling for erspan tunnel
>
> When processing icmp unreachable message for erspan tunnel, tunnel id
> should be erspan_net_id instead of ipgre_net_id.
>
> Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
> Cc: William Tu
> Signed-off-by: Haishuang Yan
> Acked-by: William Tu
> Signed-off-by: David S. Miller
>
> Fixes: 8e53509c ("gre: introduce native tunnel support for ERSPAN")
> Signed-off-by: Greg Rose
> ---
> datapath/linux/compat/ip_gre.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/datapath/linux/compat/ip_gre.c b/datapath/linux/compat/ip_gre.c
> index b7322c5..6ac2dd9 100644
> --- a/datapath/linux/compat/ip_gre.c
> +++ b/datapath/linux/compat/ip_gre.c
> @@ -312,6 +312,9 @@ static int ipgre_rcv(struct sk_buff *skb, const struct
> tnl_ptk_info *tpi,
> if (tpi->proto == htons(ETH_P_TEB))
> itn = net_generic(net, gre_tap_net_id);
> + else if (tpi->proto == htons(ETH_P_ERSPAN) ||
> + tpi->proto == htons(ETH_P_ERSPAN2))
> + itn = net_generic(net, erspan_net_id);
> else
> itn = net_generic(net, ipgre_net_id);
Thanks, applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVN/OVS Split amended proposal
On Mon, Nov 05, 2018 at 12:49:31PM -0500, Mark Michelson wrote: > On 11/02/2018 03:59 PM, Ben Pfaff wrote: > >On Fri, Nov 02, 2018 at 03:13:35PM -0400, Mark Michelson wrote: > >>With this in mind, we'd like to propose an amended plan. > > > >[...] > > > >>In order to facilitate this, OVS will need to be outfitted with ways for OVN > >>to probe for the existence of features at runtime. The most obvious use of > >>this would be ovn-controller querying ovs-vswitchd about the existence of > >>certain OpenFlow match fields and actions. > >> > >>We believe this is a more realistically achievable goal, is less likely to > >>conflict with other development projects, and is less likely to result in > >>bugs being introduced. Since this plan directly implements phases that are > >>necessary for the full separation, it acts as a stepping stone rather than a > >>band-aid or stop-gap. > >> > >>What are your thoughts on this? > > > >Seems reasonable to me. > > > >My only real comment is that I don't think new OVS features are needed > >to query for match fields and actions. I think that we can do that with > >what's already available. > > > > That's great news. > > Can you think of any other runtime incompatibilities that might exist > between OVN and OVS? I had considered differences in the running OVS > database. But I also don't think that will require anything new at runtime > to support. The database shouldn't require extra runtime support because the client library is already careful to probe for the newer server features that it wants and fall back to older features if necessary. If I think of anything else, I'll bring it up. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH V2] erspan: fix error handling for erspan tunnel
On 11/5/2018 7:52 AM, Ben Pfaff wrote:
Where can I find this patch? It is not in patchwork, nor in my personal
email archive.
Thanks,
Ben.
Here:
From: Haishuang Yan
Upstream commit:
commit 51dc63e3911fbb1f0a7a32da2fe56253e2040ea4
Author: Haishuang Yan
Date: Mon Sep 10 22:19:48 2018 +0800
erspan: fix error handling for erspan tunnel
When processing icmp unreachable message for erspan tunnel, tunnel id
should be erspan_net_id instead of ipgre_net_id.
Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
Cc: William Tu
Signed-off-by: Haishuang Yan
Acked-by: William Tu
Signed-off-by: David S. Miller
Fixes: 8e53509c ("gre: introduce native tunnel support for ERSPAN")
Signed-off-by: Greg Rose
---
datapath/linux/compat/ip_gre.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/datapath/linux/compat/ip_gre.c b/datapath/linux/compat/ip_gre.c
index b7322c5..6ac2dd9 100644
--- a/datapath/linux/compat/ip_gre.c
+++ b/datapath/linux/compat/ip_gre.c
@@ -312,6 +312,9 @@ static int ipgre_rcv(struct sk_buff *skb, const struct
tnl_ptk_info *tpi,
if (tpi->proto == htons(ETH_P_TEB))
itn = net_generic(net, gre_tap_net_id);
+ else if (tpi->proto == htons(ETH_P_ERSPAN) ||
+tpi->proto == htons(ETH_P_ERSPAN2))
+ itn = net_generic(net, erspan_net_id);
else
itn = net_generic(net, ipgre_net_id);
-- 1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH -v2] checkpatch: fix typographical error
A typographical error in a prompt for missing
python enchant library is identified and fixed.
v2:
* Rebasing done to resolve previous conflicts
Signed-off-by: Bala Sankaran
---
utilities/checkpatch.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utilities/checkpatch.py b/utilities/checkpatch.py
index 8bbda7898..41676adab 100755
--- a/utilities/checkpatch.py
+++ b/utilities/checkpatch.py
@@ -927,7 +927,7 @@ if __name__ == '__main__':
checking_file = True
elif o in ("-S", "--spellcheck-comments"):
if not open_spell_check_dict():
-print("WARNING: The enchant library isn't availble.")
+print("WARNING: The enchant library isn't available.")
print(" Please install python enchant.")
else:
spellcheck_comments = True
--
2.17.2
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVN/OVS Split amended proposal
On 11/02/2018 03:59 PM, Ben Pfaff wrote: On Fri, Nov 02, 2018 at 03:13:35PM -0400, Mark Michelson wrote: With this in mind, we'd like to propose an amended plan. [...] In order to facilitate this, OVS will need to be outfitted with ways for OVN to probe for the existence of features at runtime. The most obvious use of this would be ovn-controller querying ovs-vswitchd about the existence of certain OpenFlow match fields and actions. We believe this is a more realistically achievable goal, is less likely to conflict with other development projects, and is less likely to result in bugs being introduced. Since this plan directly implements phases that are necessary for the full separation, it acts as a stepping stone rather than a band-aid or stop-gap. What are your thoughts on this? Seems reasonable to me. My only real comment is that I don't think new OVS features are needed to query for match fields and actions. I think that we can do that with what's already available. That's great news. Can you think of any other runtime incompatibilities that might exist between OVN and OVS? I had considered differences in the running OVS database. But I also don't think that will require anything new at runtime to support. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] OVN: introduce mac_prefix support to IPAM
>
> Thanks for the patch.
Hi Ben,
thx for the review. Few comments inline.
Regards,
Lorenzo
>
> I'm not sure in what circumstances a broadcast domain would be shared
> among deployments. I tend to think of OVN L2 networks as contained.
> But I guess this patch was written for a reason, so it must be common
> enough.
>
> I can see at least two possible routes here:
>
> - The current one, in which there is a default MAC_ADDR_PREFIX. Two
> OVN deployments cannot coexist using MACAM, supposing they somehow
> share a broadcast domain, unless at least one of them manually
> selects an alternate MAC prefix. This may be desirable if it is
> important that the default MAC prefix 0A-00-00 be recognizable.
>
I preferred to maintain a default mac prefix for compatibility with
older deployments
that maybe assume to have a default mac prefix for MACAM, but if you
prefer we can
switch to the second implementation
> - An alternative would be for every OVN deployment to automatically
> select a random MAC address prefix. When ovn-northd starts, it
> would read the MAC address prefix out of NB_Global, and if there
> isn't one, generate one randomly and store it into NB_Global.
> Then there would be fewer pitfalls in setting up multiple
> deployments.
>
the only concern that come to my mind is that, is possible to have a
mac prefix collision on multiple
deployments when mac prefix is randomly chosen?
> I am OK with the one currently proposed, but I want to make sure that
> the other approach was at least considered.
>
> On Fri, Oct 26, 2018 at 04:15:27PM -0400, Mark Michelson wrote:
> > Looks good, Lorenzo,
> >
> > Just to reaaffirm my previous ack:
> >
> > Acked-by: Mark Michelson
> >
> > On 10/26/2018 12:20 PM, Lorenzo Bianconi wrote:
> > >Add the possibility to specify a given mac address prefix for
> > >dynamically generated mac address. Mac address prefix can be
> > >specified in nbdb NB_Global table, options:mac_prefix=
> > >This patch fix a possible issue of L2 address duplication if
> > >multiple OVN deployments share a single broadcast domain
> > >
> > >Acked-by: Mark Michelson
> > >Signed-off-by: Lorenzo Bianconi
> > >---
> > >Changes since v1:
> > >- use a global definition for mac_prefix
> > >---
> > > ovn/northd/ovn-northd.c | 37 ++---
> > > ovn/ovn-nb.xml | 5 +
> > > tests/ovn.at| 17 +
> > > 3 files changed, 56 insertions(+), 3 deletions(-)
> > >
> > >diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> > >index 439651f80..816c72311 100644
> > >--- a/ovn/northd/ovn-northd.c
> > >+++ b/ovn/northd/ovn-northd.c
> > >@@ -68,6 +68,7 @@ static const char *unixctl_path;
> > > /* MAC address management (macam) table of "struct eth_addr"s, that
> > > holds the
> > > * MAC addresses allocated by the OVN ipam module. */
> > > static struct hmap macam = HMAP_INITIALIZER();
> > >+static struct eth_addr mac_prefix;
> > > #define MAX_OVN_TAGS 4096
> > >
> > >@@ -922,10 +923,17 @@ ipam_insert_mac(struct eth_addr *ea, bool check)
> > > }
> > > uint64_t mac64 = eth_addr_to_uint64(*ea);
> > >+uint64_t prefix;
> > >+
> > >+if (!eth_addr_is_zero(mac_prefix)) {
> > >+prefix = eth_addr_to_uint64(mac_prefix);
> > >+} else {
> > >+prefix = MAC_ADDR_PREFIX;
> > >+}
> > > /* If the new MAC was not assigned by this address management system
> > > or
> > > * check is true and the new MAC is a duplicate, do not insert it
> > > into the
> > > * macam hmap. */
> > >-if (((mac64 ^ MAC_ADDR_PREFIX) >> 24)
> > >+if (((mac64 ^ prefix) >> 24)
> > > || (check && ipam_is_duplicate_mac(ea, mac64, true))) {
> > > return;
> > > }
> > >@@ -1036,7 +1044,11 @@ ipam_get_unused_mac(void)
> > > for (i = 0; i < MAC_ADDR_SPACE - 1; i++) {
> > > /* The tentative MAC's suffix will be in the interval (1,
> > > 0xfe). */
> > > mac_addr_suffix = ((last_mac + i) % (MAC_ADDR_SPACE - 1)) + 1;
> > >-mac64 = MAC_ADDR_PREFIX | mac_addr_suffix;
> > >+if (!eth_addr_is_zero(mac_prefix)) {
> > >+mac64 = eth_addr_to_uint64(mac_prefix) | mac_addr_suffix;
> > >+} else {
> > >+mac64 = MAC_ADDR_PREFIX | mac_addr_suffix;
> > >+}
> > > eth_addr_from_uint64(mac64, );
> > > if (!ipam_is_duplicate_mac(, mac64, false)) {
> > > last_mac = mac_addr_suffix;
> > >@@ -1107,7 +1119,15 @@ dynamic_mac_changed(const char *lsp_addresses,
> > > }
> > > uint64_t mac64 = eth_addr_to_uint64(update->current_addresses.ea);
> > >- if ((mac64 ^ MAC_ADDR_PREFIX) >> 24) {
> > >+ uint64_t prefix;
> > >+
> > >+ if (!eth_addr_is_zero(mac_prefix)) {
> > >+ prefix = eth_addr_to_uint64(mac_prefix);
> > >+ } else {
> > >+ prefix = MAC_ADDR_PREFIX;
> > >+ }
> > >+
> > >+ if ((mac64 ^ prefix) >> 24) {
> > >
Re: [ovs-dev] [PATCH v2] OVN: introduce mac_prefix support to IPAM
Thanks for the patch.
I'm not sure in what circumstances a broadcast domain would be shared
among deployments. I tend to think of OVN L2 networks as contained.
But I guess this patch was written for a reason, so it must be common
enough.
I can see at least two possible routes here:
- The current one, in which there is a default MAC_ADDR_PREFIX. Two
OVN deployments cannot coexist using MACAM, supposing they somehow
share a broadcast domain, unless at least one of them manually
selects an alternate MAC prefix. This may be desirable if it is
important that the default MAC prefix 0A-00-00 be recognizable.
- An alternative would be for every OVN deployment to automatically
select a random MAC address prefix. When ovn-northd starts, it
would read the MAC address prefix out of NB_Global, and if there
isn't one, generate one randomly and store it into NB_Global.
Then there would be fewer pitfalls in setting up multiple
deployments.
I am OK with the one currently proposed, but I want to make sure that
the other approach was at least considered.
On Fri, Oct 26, 2018 at 04:15:27PM -0400, Mark Michelson wrote:
> Looks good, Lorenzo,
>
> Just to reaaffirm my previous ack:
>
> Acked-by: Mark Michelson
>
> On 10/26/2018 12:20 PM, Lorenzo Bianconi wrote:
> >Add the possibility to specify a given mac address prefix for
> >dynamically generated mac address. Mac address prefix can be
> >specified in nbdb NB_Global table, options:mac_prefix=
> >This patch fix a possible issue of L2 address duplication if
> >multiple OVN deployments share a single broadcast domain
> >
> >Acked-by: Mark Michelson
> >Signed-off-by: Lorenzo Bianconi
> >---
> >Changes since v1:
> >- use a global definition for mac_prefix
> >---
> > ovn/northd/ovn-northd.c | 37 ++---
> > ovn/ovn-nb.xml | 5 +
> > tests/ovn.at| 17 +
> > 3 files changed, 56 insertions(+), 3 deletions(-)
> >
> >diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> >index 439651f80..816c72311 100644
> >--- a/ovn/northd/ovn-northd.c
> >+++ b/ovn/northd/ovn-northd.c
> >@@ -68,6 +68,7 @@ static const char *unixctl_path;
> > /* MAC address management (macam) table of "struct eth_addr"s, that holds
> > the
> > * MAC addresses allocated by the OVN ipam module. */
> > static struct hmap macam = HMAP_INITIALIZER();
> >+static struct eth_addr mac_prefix;
> > #define MAX_OVN_TAGS 4096
> >
> >@@ -922,10 +923,17 @@ ipam_insert_mac(struct eth_addr *ea, bool check)
> > }
> > uint64_t mac64 = eth_addr_to_uint64(*ea);
> >+uint64_t prefix;
> >+
> >+if (!eth_addr_is_zero(mac_prefix)) {
> >+prefix = eth_addr_to_uint64(mac_prefix);
> >+} else {
> >+prefix = MAC_ADDR_PREFIX;
> >+}
> > /* If the new MAC was not assigned by this address management system or
> > * check is true and the new MAC is a duplicate, do not insert it into
> > the
> > * macam hmap. */
> >-if (((mac64 ^ MAC_ADDR_PREFIX) >> 24)
> >+if (((mac64 ^ prefix) >> 24)
> > || (check && ipam_is_duplicate_mac(ea, mac64, true))) {
> > return;
> > }
> >@@ -1036,7 +1044,11 @@ ipam_get_unused_mac(void)
> > for (i = 0; i < MAC_ADDR_SPACE - 1; i++) {
> > /* The tentative MAC's suffix will be in the interval (1,
> > 0xfe). */
> > mac_addr_suffix = ((last_mac + i) % (MAC_ADDR_SPACE - 1)) + 1;
> >-mac64 = MAC_ADDR_PREFIX | mac_addr_suffix;
> >+if (!eth_addr_is_zero(mac_prefix)) {
> >+mac64 = eth_addr_to_uint64(mac_prefix) | mac_addr_suffix;
> >+} else {
> >+mac64 = MAC_ADDR_PREFIX | mac_addr_suffix;
> >+}
> > eth_addr_from_uint64(mac64, );
> > if (!ipam_is_duplicate_mac(, mac64, false)) {
> > last_mac = mac_addr_suffix;
> >@@ -1107,7 +1119,15 @@ dynamic_mac_changed(const char *lsp_addresses,
> > }
> > uint64_t mac64 = eth_addr_to_uint64(update->current_addresses.ea);
> >- if ((mac64 ^ MAC_ADDR_PREFIX) >> 24) {
> >+ uint64_t prefix;
> >+
> >+ if (!eth_addr_is_zero(mac_prefix)) {
> >+ prefix = eth_addr_to_uint64(mac_prefix);
> >+ } else {
> >+ prefix = MAC_ADDR_PREFIX;
> >+ }
> >+
> >+ if ((mac64 ^ prefix) >> 24) {
> > return DYNAMIC;
> > } else {
> > return NONE;
> >@@ -7141,6 +7161,17 @@ ovnnb_db_run(struct northd_context *ctx,
> > sbrec_sb_global_set_options(sb, >options);
> > sb_loop->next_cfg = nb->nb_cfg;
> >+const char *mac_addr_prefix = smap_get(>options, "mac_prefix");
> >+if (mac_addr_prefix) {
> >+struct eth_addr addr;
> >+
> >+memset(, 0, sizeof addr);
> >+if (ovs_scan(mac_addr_prefix, "%"SCNx8":%"SCNx8":%"SCNx8,
> >+ [0], [1], [2])) {
> >+mac_prefix = addr;
> >+}
> >+}
> >+
> > cleanup_macam();
> > }
> >diff --git
[ovs-dev] [PATCH] [RFC] Add a new OVS action check_pkt_larger
From: Numan Siddique
This patch adds a new action 'check_pkt_larger' which checks if the
packet is larger than the given size and stores the result in the
destination register.
Usage: check_pkt_larger:len->REGISTER
Eg. match=...,actions=check_pkt_larger:1442->NXM_NX_REG0[0],next;
When translating this action, SLOW_ACTION is set so that datapath
flow is not added.
This action is intended to be used by OVN to check the packet length
and generate an ICMP packet with type 3, code 4 and next hop mtu
in the logical router pipeline if the MTU of the physical interface
is lesser than the packet length. More information can be found here [1]
TODO:
- Add test case.
- Change the action format from check_pkt_larger:len to check_pkt_larger(len)
Request to suggest a better name for the action in case 'check_pkt_larger'
seems odd.
[1] - https://mail.openvswitch.org/pipermail/ovs-discuss/2018-July/047039.html
Signed-off-by: Numan Siddique
---
include/openvswitch/ofp-actions.h | 11
lib/ofp-actions.c | 95 ++-
ofproto/ofproto-dpif-xlate.c | 23
3 files changed, 128 insertions(+), 1 deletion(-)
diff --git a/include/openvswitch/ofp-actions.h
b/include/openvswitch/ofp-actions.h
index e0588afad..2ec045fe5 100644
--- a/include/openvswitch/ofp-actions.h
+++ b/include/openvswitch/ofp-actions.h
@@ -123,6 +123,8 @@ struct vl_mff_map;
OFPACT(NAT, ofpact_nat, ofpact, "nat") \
OFPACT(OUTPUT_TRUNC,ofpact_output_trunc,ofpact, "output_trunc") \
OFPACT(CLONE, ofpact_nest,actions, "clone") \
+OFPACT(CHECK_PKT_LARGER, ofpact_check_pkt_larger, ofpact, \
+ "check_pkt_larger") \
\
/* Debugging actions. \
* \
@@ -572,6 +574,15 @@ struct ofpact_meter {
uint32_t provider_meter_id;
};
+/* OFPACT_CHECK_PKT_LARGER.
+ *
+ * Used for NXAST_CHECK_PKT_LARGER. */
+struct ofpact_check_pkt_larger {
+struct ofpact ofpact;
+uint16_t pkt_len;
+struct mf_subfield dst;
+};
+
/* OFPACT_WRITE_ACTIONS, OFPACT_CLONE.
*
* Used for OFPIT11_WRITE_ACTIONS, NXAST_CLONE. */
diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
index a80a4a308..5fd61de8a 100644
--- a/lib/ofp-actions.c
+++ b/lib/ofp-actions.c
@@ -355,6 +355,8 @@ enum ofp_raw_action_type {
/* NX1.3+(48): void. */
NXAST_RAW_DEC_NSH_TTL,
+/* NX1.0+(49): struct nx_action_check_pkt_larger, ... */
+OFPAT_RAW_CHECK_PKT_LARGER,
/* ## -- ## */
/* ## Debugging actions. ## */
/* ## -- ## */
@@ -492,6 +494,7 @@ ofpact_next_flattened(const struct ofpact *ofpact)
case OFPACT_ENCAP:
case OFPACT_DECAP:
case OFPACT_DEC_NSH_TTL:
+case OFPACT_CHECK_PKT_LARGER:
return ofpact_next(ofpact);
case OFPACT_CLONE:
@@ -7399,6 +7402,94 @@ check_WRITE_METADATA(const struct ofpact_metadata *a
OVS_UNUSED,
return 0;
}
+/* Check packet length action. */
+
+struct nx_action_check_pkt_larger {
+ovs_be16 type; /* OFPAT_VENDOR. */
+ovs_be16 len; /* 24. */
+ovs_be32 vendor;/* NX_VENDOR_ID. */
+ovs_be16 subtype; /* NXAST_OUTPUT_REG. */
+uint8_t pad[6];
+ovs_be16 pkt_len; /* Length of the packet to check. */
+ovs_be16 ofs_nbits; /* (ofs << 6) | (n_bits - 1). */
+ovs_be32 dst; /* Destination register. */
+};
+
+OFP_ASSERT(sizeof(struct nx_action_check_pkt_larger) == 24);
+
+static enum ofperr
+decode_OFPAT_RAW_CHECK_PKT_LARGER(
+const struct nx_action_check_pkt_larger *ncpl,
+enum ofp_version ofp_version OVS_UNUSED, struct ofpbuf *out)
+{
+struct ofpact_check_pkt_larger *check_pkt_larger =
+ofpact_put_CHECK_PKT_LARGER(out);
+check_pkt_larger->pkt_len = ntohs(ncpl->pkt_len);
+const struct mf_field *mf = mf_from_nxm_header(ntohl(ncpl->dst), NULL);
+check_pkt_larger->dst.field = mf;
+check_pkt_larger->dst.ofs = nxm_decode_ofs(ncpl->ofs_nbits);
+check_pkt_larger->dst.n_bits = nxm_decode_n_bits(ncpl->ofs_nbits);;
+return 0;
+}
+
+static void
+encode_CHECK_PKT_LARGER(const struct ofpact_check_pkt_larger *check_pkt_larger,
+ enum ofp_version ofp_version OVS_UNUSED,
+ struct ofpbuf *out OVS_UNUSED)
+{
+struct nx_action_check_pkt_larger *ncpl = put_OFPAT_CHECK_PKT_LARGER(out);
+ncpl->pkt_len = htons(check_pkt_larger->pkt_len);
+ncpl->ofs_nbits = nxm_encode_ofs_nbits(
+check_pkt_larger->dst.ofs, check_pkt_larger->dst.n_bits);
+if (check_pkt_larger->dst.field) {
+ncpl->dst = htonl(nxm_header_from_mff(check_pkt_larger->dst.field));
+}
+}
+
+static char * OVS_WARN_UNUSED_RESULT
+parse_CHECK_PKT_LARGER(char *arg,
Re: [ovs-dev] [PATCH] checkpatch: fix a typographical error
- Original Message - > From: "Ben Pfaff" > To: "Bala Sankaran" > Cc: ovs-dev@openvswitch.org > Sent: Monday, November 5, 2018 10:10:07 AM > Subject: Re: [ovs-dev] [PATCH] checkpatch: fix a typographical error > > On Mon, Nov 05, 2018 at 09:38:23AM -0500, Bala Sankaran wrote: > > A typographical error in a prompt for missing > > python enchant library is identified and fixed. > > > > Signed-off-by: Bala Sankaran > > Thanks for the fix. > > This patch doesn't apply, probably because of a recent change in the > same area. Would you mind rebasing? > Rebasing done. Thank you. - Bala Sankaran Networking Services Intern Red Hat Inc ., ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH V2] erspan: fix error handling for erspan tunnel
Where can I find this patch? It is not in patchwork, nor in my personal
email archive.
Thanks,
Ben.
On Thu, Nov 01, 2018 at 09:29:54AM -0700, Gregory Rose wrote:
> On 11/1/2018 9:04 AM, William Tu wrote:
> >Looks good to me, sorry for my late reply!
>
> No worries, it sort of fell off my radar as well.
>
> >
> >On Fri, Sep 21, 2018 at 7:54 AM Greg Rose wrote:
> >>From: Haishuang Yan
> >>
> >>Upstream commit:
> >> commit 51dc63e3911fbb1f0a7a32da2fe56253e2040ea4
> >> Author: Haishuang Yan
> >> Date: Mon Sep 10 22:19:48 2018 +0800
> >>
> >> erspan: fix error handling for erspan tunnel
> >>
> >> When processing icmp unreachable message for erspan tunnel, tunnel id
> >> should be erspan_net_id instead of ipgre_net_id.
> >>
> >> Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
> >> Cc: William Tu
> >> Signed-off-by: Haishuang Yan
> >> Acked-by: William Tu
> >> Signed-off-by: David S. Miller
> >>
> >>Fixes: 8e53509c ("gre: introduce native tunnel support for ERSPAN")
> >>Signed-off-by: Greg Rose
> >>---
> >Acked-by: William Tu
>
> Thanks!
>
> - Greg
> ___
> 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] ovn-northd: Always set nat_addresses and options in Port_Binding.
On Mon, Nov 05, 2018 at 08:55:51PM +0530, Numan Siddique wrote: > On Fri, Nov 2, 2018 at 10:40 PM Ben Pfaff wrote: > > > In some cases the code didn't set these columns. > > > > Found by inspection. > > > > Signed-off-by: Ben Pfaff > > > > Acked-by: Numan Siddique Thanks, applied to master. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] odp-util: Validate close-brace in scan_geneve and fix return values of san_xxx functions
On Thu, Nov 01, 2018 at 10:33:03AM -0700, Yifeng Sun wrote:
> This patch adds validation of close-braces in scan_geneve. An simple
> example is "set(encap(tunnel(geneve({{". When scan_geneve returns,
> (struct geneve_scan *key)->len equals to 2*sizeof(struct geneve_opt).
> That seems not correct.
>
> Found this issue while inspecting oss-fuzz
> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11153.
>
> In addition, SCAN_TYPE expects scan_XXX functions to return 0
> on errors. This patch inspects all related scan_XXX functions
> and fixes their return values.
>
> Signed-off-by: Yifeng Sun
Thanks, applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovn-northd: Always set nat_addresses and options in Port_Binding.
On Fri, Nov 2, 2018 at 10:40 PM Ben Pfaff wrote:
> In some cases the code didn't set these columns.
>
> Found by inspection.
>
> Signed-off-by: Ben Pfaff
>
Acked-by: Numan Siddique
> ---
> ovn/northd/ovn-northd.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index e42ceea99264..665b0d820a05 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -2170,6 +2170,8 @@ ovn_port_update_sbrec(struct northd_context *ctx,
>
> struct smap ids = SMAP_INITIALIZER();
> sbrec_port_binding_set_external_ids(op->sb, );
> +
> +sbrec_port_binding_set_nat_addresses(op->sb, NULL, 0);
> } else {
> if (strcmp(op->nbsp->type, "router")) {
> uint32_t queue_id = smap_get_int(
> @@ -2202,6 +2204,8 @@ ovn_port_update_sbrec(struct northd_context *ctx,
> , "Unknown port type '%s' set on logical switch
> '%s'.",
> op->nbsp->type, op->nbsp->name);
> }
> +
> +sbrec_port_binding_set_nat_addresses(op->sb, NULL, 0);
> } else {
> const char *chassis = NULL;
> if (op->peer && op->peer->od && op->peer->od->nbr) {
> @@ -2229,6 +2233,8 @@ ovn_port_update_sbrec(struct northd_context *ctx,
> }
> sbrec_port_binding_set_options(op->sb, );
> smap_destroy();
> +} else {
> +sbrec_port_binding_set_options(op->sb, NULL);
> }
>
> const char *nat_addresses = smap_get(>nbsp->options,
> --
> 2.16.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 v4] ovn-nbctl: Fix the ovn-nbctl test "LBs - daemon" which fails during rpm build
On Fri, Nov 02, 2018 at 05:11:01PM +0530, nusid...@redhat.com wrote: > From: Numan Siddique > > When 'make check' is called by the mock rpm build (which disables networking), > the test "ovn-nbctl: LBs - daemon" fails when it runs the command > "ovn-nbctl lb-add lb0 30.0.0.1a 192.168.10.10:80,192.168.10.20:80". ovn-nbctl > extracts the vip by calling the socket util function 'inet_parse_active()', > and this function blocks when libunbound function ub_resolve() is called > further down. ub_resolve() is a blocking function without timeout and all the > ovs/ovn utilities use this function. > > As reported by Timothy Redaelli, the issue can also be reproduced by running > the below commands > > $ sudo unshare -mn -- sh -c 'ip addr add dev lo 127.0.0.1 && \ > mount --bind /dev/null /etc/resolv.conf && runuser $SUDO_USER' > $ make sandbox SANDBOXFLAGS="--ovn" > $ ovn-nbctl -vsocket_util:off lb-add lb0 30.0.0.1a \ > 192.168.10.10:80,192.168.10.20:80 > > To address this issue, this patch adds a new bool argument 'resolve_host' to > the function inet_parse_active() to resolve the host only if it is 'true'. > > ovn-nbctl/ovn-northd will pass 'false' when it calls this function to parse > the load balancer values. > > Reported-by: Timothy Redaelli > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1641672 > Signed-off-by: Numan Siddique Thanks, applied to master. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] checkpatch: fix a typographical error
On Mon, Nov 05, 2018 at 09:38:23AM -0500, Bala Sankaran wrote: > A typographical error in a prompt for missing > python enchant library is identified and fixed. > > Signed-off-by: Bala Sankaran Thanks for the fix. This patch doesn't apply, probably because of a recent change in the same area. Would you mind rebasing? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] checkpatch: fix a typographical error
Bleep bloop. Greetings Bala Sankaran, I am a robot and I have tried out your patch. Thanks for your contribution. I encountered some error that I wasn't expecting. See the details below. git-am: Failed to merge in the changes. Patch failed at 0001 checkpatch: fix a typographical error The copy of the patch that failed is found in: /var/lib/jenkins/jobs/upstream_build_from_pw/workspace/.git/rebase-apply/patch When you have resolved this problem, run "git am --resolved". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Please check this out. If you feel there has been an error, please email acon...@bytheb.org Thanks, 0-day Robot ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] checkpatch: fix a typographical error
A typographical error in a prompt for missing
python enchant library is identified and fixed.
Signed-off-by: Bala Sankaran
---
utilities/checkpatch.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utilities/checkpatch.py b/utilities/checkpatch.py
index 5f5dd8318..22f168409 100755
--- a/utilities/checkpatch.py
+++ b/utilities/checkpatch.py
@@ -917,7 +917,7 @@ if __name__ == '__main__':
checking_file = True
elif o in ("-S", "--spellcheck-comments"):
if no_spellcheck:
-print("WARNING: The enchant library isn't availble.")
+print("WARNING: The enchant library isn't available.")
print(" Please install python enchant.")
else:
spellcheck_comments = True
--
2.17.2
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] b2b executives leads
Hi, Hope you are doing well! We are global data base vendors and we do maintain *42 million records from all industry globally.* Please let me know if you would like to reach any of your target criteria, will get back to you with the *counts and cost information*. The major industries that we focus are Technology, Healthcare, Marketing, Education, oil and Gas, Real Estate, Telecommunications, Finance and Banking, Manufacturing, Publishing, Retail, Travel, Automotive etc. You can also let us know of there is any other industries or requirement that you have so that we can provide you with customized solutions as well. Please provide your target audience in below mentioned parameters. *Target Industry :*___ (Any Industry) *Target Geography:* (Worldwide) *Target Job Titles :* _ (ex: CEO, VP, Director or any other decision makers) Look forward to hear from you. *Best Regards,* *Janessa Glory* *Senior Marketing Manager* *Smart Marketing Group* - *Save marketing dollars!* BNY Mellon Centre, 1635 Market Street Suite 3750, Philadelphia, Pennsylvania, USA 19103 -- To remove from this mailing: reply with subject line as "Leave out " and indicate your email address to be removed from our database. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVS DPDK: dpdk_merge pull request for master
> On Fri, Nov 02, 2018 at 05:33:39PM +, Stokes, Ian wrote: > > Hi Ben, > > > > The following changes since commit > af26093ab197c309dc0cfa83c5a2db34706f6021: > > > > connmgr: Improve interface for setting controllers. (2018-10-31 > 16:04:36 -0700) > > > > are available in the git repository at: > > > > https://github.com/istokes/ovs dpdk_merge > > > > for you to fetch changes up to 3aaa62015158581dea8de162555abab353f90e8b: > > > > dp-packet: Fix allocated size on DPDK init. (2018-11-02 16:29:14 > +) > > Thanks. I merged this into master. Thanks Ben. Ian ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
