Re: [ovs-dev] [PATCH] netdev-offload-tc: Flush rules on ingress block when init tc flow api
On 2020-02-27 5:22 PM, Roi Dayan wrote:
> From: Dmytro Linkin
>
> OVS can fail to attach ingress block on iface when init tc flow api,
> if block already exist with rules on it and is shared with other iface.
> Fix by flush all existing rules on the ingress block prior to deleting
> it.
>
> Fixes: 093c9458fb02 ("tc: allow offloading of block ids")
> Signed-off-by: Dmytro Linkin
> Acked-by: Raed Salem
> Acked-by: Roi Dayan
> ---
> lib/netdev-offload-tc.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/lib/netdev-offload-tc.c b/lib/netdev-offload-tc.c
> index 550e440b3a45..b5ff6ccca55e 100644
> --- a/lib/netdev-offload-tc.c
> +++ b/lib/netdev-offload-tc.c
> @@ -1907,6 +1907,7 @@ netdev_tc_init_flow_api(struct netdev *netdev)
> static struct ovsthread_once block_once = OVSTHREAD_ONCE_INITIALIZER;
> enum tc_qdisc_hook hook = get_tc_qdisc_hook(netdev);
> uint32_t block_id = 0;
> +struct tcf_id id;
> int ifindex;
> int error;
>
> @@ -1917,6 +1918,14 @@ netdev_tc_init_flow_api(struct netdev *netdev)
> return -ifindex;
> }
>
> +block_id = get_block_id_from_netdev(netdev);
> +
> +/* Flush rules explicitly needed when we work with ingress_block,
> + * so we will not fail with reattaching block to bond iface, for ex.
> + */
> +id = tc_make_tcf_id(ifindex, block_id, 0, hook);
> +tc_del_filter();
> +
> /* make sure there is no ingress/egress qdisc */
> tc_add_del_qdisc(ifindex, false, 0, hook);
>
> @@ -1930,7 +1939,6 @@ netdev_tc_init_flow_api(struct netdev *netdev)
> ovsthread_once_done(_mask_once);
> }
>
> -block_id = get_block_id_from_netdev(netdev);
> error = tc_add_del_qdisc(ifindex, true, block_id, hook);
>
> if (error && error != EEXIST) {
>
+ilya
Hi Ilya,
can you help review/ack this?
Thanks,
Roi
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovsdb-idl.c: Clear conditions when clearing IDL.
On Mon, Mar 2, 2020 at 7:55 AM Dumitru Ceara wrote:
>
> On 2/29/20 12:00 AM, Dumitru Ceara wrote:
> > If the ovsdb-server reply to "monitor_cond_since" requests has
> > "found" == false then ovsdb_idl_db_parse_monitor_reply() calls
> > ovsdb_idl_db_clear() which iterates through all tables and
> > unconditionally sets table->cond_changed to false.
> >
> > However, if the client had already set a new condition for some of the
> > tables, this new condition request will never be sent to ovsdb-server
> > until the condition is reset to a different value. This is due to the
> > check in ovsdb_idl_db_set_condition().
> >
> > In order to fix this we now also call ovsdb_idl_condition_clear() for
> > each table condition in ovsdb_idl_db_clear(). This ensures that
> > resetting the condition to the same value as before the
> > "monitor_cond_since" reply will trigger a new request.
> >
> > One way to replicate the issue is described in the bugzilla reporting
> > the bug, when ovn-controller is configured to use "ovn-monitor-all":
> > https://bugzilla.redhat.com/show_bug.cgi?id=1808125#c6
> >
> > Reported-by: Dan Williams
> > Reported-at: https://bugzilla.redhat.com/1808125
> > CC: Han Zhou
> > Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when
connection reset.")
> > Signed-off-by: Dumitru Ceara
>
> Hi Han,
>
> I was wondering if you could review this change because ovn-kubernetes
> is trying to enable ovn-monitor-all for scalability reasons but their CI
> fails due to the bug fixed by the patch below.
>
> Thanks,
> Dumitru
>
> > ---
> > lib/ovsdb-idl.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/ovsdb-idl.c b/lib/ovsdb-idl.c
> > index 190143f..64721ca 100644
> > --- a/lib/ovsdb-idl.c
> > +++ b/lib/ovsdb-idl.c
> > @@ -610,7 +610,11 @@ ovsdb_idl_db_clear(struct ovsdb_idl_db *db)
> > struct ovsdb_idl_table *table = >tables[i];
> > struct ovsdb_idl_row *row, *next_row;
> >
> > -table->cond_changed = false;
> > +if (table->cond_changed) {
> > +table->cond_changed = false;
> > +ovsdb_idl_condition_clear(>condition);
> > +}
> > +
> > if (hmap_is_empty(>rows)) {
> > continue;
> > }
> >
>
Hi Dumitru,
If I understand the problem, it is when the client updated monitor
condition and at the same time it received monitor_cond_since reply from
server for it's previous conditional monitor request, and the handling of
the reply overwrite the flag table->cond_changed from true to false, and
because of this, the new condition is not sent to server.
However, I don't understand the fix. It seems that the fix should be "don't
overwrite the flag", instead of clearing the conditions as well. Also, by
simply looking at this code I don't understand why the flag needs to be set
to false when clearing data in IDL. What would be the problem if we keep it
as what it is? If you understand the details, could you explain more about
the fix?
In addition, I didn't change this logic when implementing
monitor_cond_since in 403a6a0cb003 ("ovsdb-idl: Fast resync from server
when connection reset."). In that commit it only reduced the chance of
calling ovsdb_idl_db_clear() as an optimization. Before that commit,
ovsdb_idl_db_parse_monitor_reply() always calls ovsdb_idl_db_clear() and it
would result in same problem.
Thanks,
Han
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH net 08/16] openvswitch: add missing attribute validation for hash
Add missing attribute validation for OVS_PACKET_ATTR_HASH
to the netlink policy.
Fixes: bd1903b7c459 ("net: openvswitch: add hash info to upcall")
Signed-off-by: Jakub Kicinski
---
CC: Pravin B Shelar
CC: Tonghao Zhang
CC: d...@openvswitch.org
---
net/openvswitch/datapath.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index c047afd12116..07a7dd185995 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -645,6 +645,7 @@ static const struct nla_policy
packet_policy[OVS_PACKET_ATTR_MAX + 1] = {
[OVS_PACKET_ATTR_ACTIONS] = { .type = NLA_NESTED },
[OVS_PACKET_ATTR_PROBE] = { .type = NLA_FLAG },
[OVS_PACKET_ATTR_MRU] = { .type = NLA_U16 },
+ [OVS_PACKET_ATTR_HASH] = { .type = NLA_U64 },
};
static const struct genl_ops dp_packet_genl_ops[] = {
--
2.24.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] 答复: [PATCH] userspace-tso: Document the minimum kernel version.
I totally agree with Flavio, ovs document is the best place to tell users where
the issue is and how it should be fixed, maybe the statement is not that
correct for distribution kernel, but it is indeed very valuable information for
end users, new statement obviously fixed Ilya's concerns.
-邮件原件-
发件人: Flavio Leitner [mailto:f...@sysclose.org]
发送时间: 2020年3月3日 3:52
收件人: Ilya Maximets
抄送: d...@openvswitch.org; Yi Yang (杨燚)-云服务集团
主题: Re: [ovs-dev] [PATCH] userspace-tso: Document the minimum kernel version.
On Mon, Mar 02, 2020 at 01:11:35PM +0100, Ilya Maximets wrote:
> On 2/28/20 11:58 PM, Flavio Leitner wrote:
> > The kernel needs to be at least 4.19-rc7 to include the commit
> > 9d2f67e43b73 ("net/packet: fix packet drop as of virtio gso")
> > otherwise the TSO packets are dropped when using raw sockets.
> >
> > Fixes: 29cf9c1b3b9c ("userspace: Add TCP Segmentation Offload
> > support")
> > Reported-by: Yi Yang (杨燚)-云服务集团
> > Signed-off-by: Flavio Leitner
> > ---
> > Documentation/topics/userspace-tso.rst | 4
> > 1 file changed, 4 insertions(+)
> >
> > This applies to branch-2.13 as well.
> >
> > diff --git a/Documentation/topics/userspace-tso.rst
> > b/Documentation/topics/userspace-tso.rst
> > index 0fbac93a5..da370e64f 100644
> > --- a/Documentation/topics/userspace-tso.rst
> > +++ b/Documentation/topics/userspace-tso.rst
> > @@ -113,6 +113,10 @@ __ https://patches.dpdk.org/patch/64136/
> > This fix is expected to be included in the 19.11.1 release. When
> > OVS migrates to this DPDK release, this limitation can be removed.
> >
> > +All kernel devices that use the raw socket interface (veth, for
> > +example) require a kernel with minimum version of 4.19-rc7 to include the
> > commit:
> > +9d2f67e43b73 ("net/packet: fix packet drop as of virtio gso").
>
> I'm not very happy with this kind of documentation updates. The main
> reason is that every distribution uses their own custom kernel with
> some patches backported or not. In this particular case we seem to
> have issue with particular ubuntu kernel that happened to not have this bug
> fix backported.
> If someone uses non-lognterm upstream kernel that is out of its
> support lifetime it's his/her responsibility to backport bugfixes.
> Upstream LTS kernel 4.14 has this bugfix backported and there should
> be no issues. Upstream LTS 4.9 might not have this issue at all and
> work fine (I didn't check).
>
> What we can document is that particular kernel version from the Ubuntu
> 16.04 distribution has an issue and should not be used along with
> userspace-tso.
> Ideally, someone should file a bug for ubuntu kernel maintainers, so
> they will backport relevant patch and update their kernel since it's
> still in a supported state. In this case we will have no need to document
> anything.
>
> What do you think?
I think worth for Ubuntu users to open a bug, so that this gets solved.
But I think the documentation is still valid. Yi and I spent time to find the
root cause and it is something out of OvS control, so the best we can do is
document the requirement.
Maybe we can word it differently so that the kernel version becomes less
relevant. For example:
"All kernel devices that use the raw socket interface (veth, for example)
require the kernel commit 9d2f67e43b73 ("net/packet: fix packet drop as of
virtio gso") in order to work properly. This commit was merged in upstream
kernel 4.19-rc7, so make sure your kernel is either newer or contains the
backport."
How does that sound to you now?
Thanks,
--
fbl
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVN 20.03.0 Released
On Mon, Mar 02, 2020 at 02:14:16PM -0500, Mark Michelson wrote: > Hi everyone, > > I'm happy to announce that OVN 20.03.0 has been tagged and released. You > should be able to get the v20.03.0 tag from github [1]. Thanks to everyone's > hard work to get this release made. > > I'm announcing the release here, but it also would be good if it could be > announced on the openvswitch website since we still do not have an > operational OVN site at this time. > > Ben, would that be appropriate for me to add? Yes. Will you submit a pull request? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] userspace-tso: Document the minimum kernel version.
On Mon, Mar 02, 2020 at 01:11:35PM +0100, Ilya Maximets wrote:
> On 2/28/20 11:58 PM, Flavio Leitner wrote:
> > The kernel needs to be at least 4.19-rc7 to include the commit
> > 9d2f67e43b73 ("net/packet: fix packet drop as of virtio gso")
> > otherwise the TSO packets are dropped when using raw sockets.
> >
> > Fixes: 29cf9c1b3b9c ("userspace: Add TCP Segmentation Offload support")
> > Reported-by: Yi Yang (杨燚)-云服务集团
> > Signed-off-by: Flavio Leitner
> > ---
> > Documentation/topics/userspace-tso.rst | 4
> > 1 file changed, 4 insertions(+)
> >
> > This applies to branch-2.13 as well.
> >
> > diff --git a/Documentation/topics/userspace-tso.rst
> > b/Documentation/topics/userspace-tso.rst
> > index 0fbac93a5..da370e64f 100644
> > --- a/Documentation/topics/userspace-tso.rst
> > +++ b/Documentation/topics/userspace-tso.rst
> > @@ -113,6 +113,10 @@ __ https://patches.dpdk.org/patch/64136/
> > This fix is expected to be included in the 19.11.1 release. When OVS
> > migrates
> > to this DPDK release, this limitation can be removed.
> >
> > +All kernel devices that use the raw socket interface (veth, for example)
> > +require a kernel with minimum version of 4.19-rc7 to include the commit:
> > +9d2f67e43b73 ("net/packet: fix packet drop as of virtio gso").
>
> I'm not very happy with this kind of documentation updates. The main reason
> is that every distribution uses their own custom kernel with some patches
> backported or not. In this particular case we seem to have issue with
> particular ubuntu kernel that happened to not have this bug fix backported.
> If someone uses non-lognterm upstream kernel that is out of its support
> lifetime it's his/her responsibility to backport bugfixes.
> Upstream LTS kernel 4.14 has this bugfix backported and there should be
> no issues. Upstream LTS 4.9 might not have this issue at all and work
> fine (I didn't check).
>
> What we can document is that particular kernel version from the Ubuntu 16.04
> distribution has an issue and should not be used along with userspace-tso.
> Ideally, someone should file a bug for ubuntu kernel maintainers, so they
> will backport relevant patch and update their kernel since it's still in a
> supported state. In this case we will have no need to document anything.
>
> What do you think?
I think worth for Ubuntu users to open a bug, so that this gets
solved.
But I think the documentation is still valid. Yi and I spent time
to find the root cause and it is something out of OvS control, so
the best we can do is document the requirement.
Maybe we can word it differently so that the kernel version becomes
less relevant. For example:
"All kernel devices that use the raw socket interface (veth, for example)
require the kernel commit 9d2f67e43b73 ("net/packet: fix packet drop
as of virtio gso") in order to work properly. This commit was merged
in upstream kernel 4.19-rc7, so make sure your kernel is either
newer or contains the backport."
How does that sound to you now?
Thanks,
--
fbl
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] doc: Add AF_PACKET limitation on userspace tso.
Hi William,
I've posted this one instead few days ago:
https://mail.openvswitch.org/pipermail/ovs-dev/2020-February/368255.html
Please have a look.
Thanks,
fbl
On Mon, Mar 02, 2020 at 11:06:21AM -0800, William Tu wrote:
> For enabling TSO on devices using AF_PACKET, minimum supported
> kernel version is 4.19 due to a virtio GSO fix
> 9d2f67e43b73 ("net/packet: fix packet drop as of virtio gso")
>
> Reported-by: Yi Yang
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-dev/2020-March/368281.html
> Signed-off-by: William Tu
> ---
> Documentation/topics/userspace-tso.rst | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/topics/userspace-tso.rst
> b/Documentation/topics/userspace-tso.rst
> index 0fbac93a54d7..4c2de50075d5 100644
> --- a/Documentation/topics/userspace-tso.rst
> +++ b/Documentation/topics/userspace-tso.rst
> @@ -98,6 +98,10 @@ in Open vSwitch. Currently, if the NIC supports that, then
> the feature is
> enabled, otherwise TSO can still be enabled but SCTP packets sent to the NIC
> will be dropped.
>
> +For enabling TSO on devices using AF_PACKET, minimum supported kernel version
> +is 4.19. This is due to a virtio GSO fix:
> +9d2f67e43b73 ("net/packet: fix packet drop as of virtio gso")
> +
> There is no software implementation of TSO, so all ports attached to the
> datapath must support TSO or packets using that feature will be dropped
> on ports without TSO support. That also means guests using vhost-user
> --
> 2.7.4
>
--
fbl
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] OVN 20.03.0 Released
Hi everyone, I'm happy to announce that OVN 20.03.0 has been tagged and released. You should be able to get the v20.03.0 tag from github [1]. Thanks to everyone's hard work to get this release made. I'm announcing the release here, but it also would be good if it could be announced on the openvswitch website since we still do not have an operational OVN site at this time. Ben, would that be appropriate for me to add? Thanks, Mark [1] https://github.com/ovn-org/ovn/releases/tag/v20.03.0 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] 答复: 答复: [PATCH v4 0/3] Add support for TSO with DPDK
On Fri, Feb 28, 2020 at 9:56 AM Flavio Leitner wrote:
>
>
> Hi Yi Yang,
>
> This is the bug fix required to make veth TSO work in OvS:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d2f67e43b73e8af7438be219b66a5de0cfa8bd9
>
> commit 9d2f67e43b73e8af7438be219b66a5de0cfa8bd9
> Author: Jianfeng Tan
> Date: Sat Sep 29 15:41:27 2018 +
>
> net/packet: fix packet drop as of virtio gso
>
> When we use raw socket as the vhost backend, a packet from virito with
> gso offloading information, cannot be sent out in later validaton at
> xmit path, as we did not set correct skb->protocol which is further used
> for looking up the gso function.
>
> To fix this, we set this field according to virito hdr information.
>
> Fixes: e858fae2b0b8f4 ("virtio_net: use common code for virtio_net_hdr
> and skb GSO conversion")
> Signed-off-by: Jianfeng Tan
> Signed-off-by: David S. Miller
>
>
> So, the minimum kernel version is 4.19.
>
Thanks,
I sent a patch to update the documentation. Please take a look.
William
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] doc: Add AF_PACKET limitation on userspace tso.
For enabling TSO on devices using AF_PACKET, minimum supported
kernel version is 4.19 due to a virtio GSO fix
9d2f67e43b73 ("net/packet: fix packet drop as of virtio gso")
Reported-by: Yi Yang
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-dev/2020-March/368281.html
Signed-off-by: William Tu
---
Documentation/topics/userspace-tso.rst | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/topics/userspace-tso.rst
b/Documentation/topics/userspace-tso.rst
index 0fbac93a54d7..4c2de50075d5 100644
--- a/Documentation/topics/userspace-tso.rst
+++ b/Documentation/topics/userspace-tso.rst
@@ -98,6 +98,10 @@ in Open vSwitch. Currently, if the NIC supports that, then
the feature is
enabled, otherwise TSO can still be enabled but SCTP packets sent to the NIC
will be dropped.
+For enabling TSO on devices using AF_PACKET, minimum supported kernel version
+is 4.19. This is due to a virtio GSO fix:
+9d2f67e43b73 ("net/packet: fix packet drop as of virtio gso")
+
There is no software implementation of TSO, so all ports attached to the
datapath must support TSO or packets using that feature will be dropped
on ports without TSO support. That also means guests using vhost-user
--
2.7.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] doc: document the nointegritychecks setting.
OVS kernel module requires to turn on the 'nointegritychecks'. It has following limitations: nointegritychecks [ on | off ] Disables integrity checks. Cannot be set when secure boot is enabled. This value is ignored by Windows 7 and Windows 8. https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/bcdedit--set Signed-off-by: William Tu --- Documentation/intro/install/windows.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/intro/install/windows.rst b/Documentation/intro/install/windows.rst index 394572f001e9..579e41b73d8e 100644 --- a/Documentation/intro/install/windows.rst +++ b/Documentation/intro/install/windows.rst @@ -287,6 +287,8 @@ Enforcement' during boot. The following commands can be used: .. note:: You may have to restart the machine for the settings to take effect. + The nointegritychecks cannot be set when secure boot is enabled and + the value is ignored by Windows 8. In the Virtual Switch Manager configuration you can enable the Open vSwitch Extension on an existing switch or create a new switch. If you are using an -- 2.7.4 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] netdev-linux: Enable TSO in the TAP device.
On Sat, Feb 29, 2020 at 08:29:35PM -0300, Flavio Leitner wrote:
> Use ioctl TUNSETOFFLOAD if kernel supports to enable TSO
> offloading in the tap device.
>
> Fixes: 29cf9c1b3b9c ("userspace: Add TCP Segmentation Offload support")
> Reported-by: "Yi Yang (杨�D)-云服务集团"
> Tested-by: William Tu
> Signed-off-by: Flavio Leitner
> ---
Thanks, I applied to master.
Currently there is no consistent way to test TSO.
So I tested your patch using
$ make check-system-tso
in this patch under review:
https://patchwork.ozlabs.org/patch/1241630/
https://patchwork.ozlabs.org/patch/1241631/
Regards,
William
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Urgent Reply!!!
Sorry to break into your privacy in this manner, I'm Smadar Barber-Tsadik, Deputy Chief Executive Officer of First International Bank of Israel Ltd (FIBI). I am getting in touch with you regarding an extremely important and urgent matter. If you would oblige me the opportunity, I shall provide you with details upon your response. Faithfully, Smadar Barber-Tsadik ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovs-dpctl-top: python3 compatibility
On Mon, Mar 02, 2020 at 11:05:06AM -0500, Aaron Conole wrote:
> During the transition to python3 support, some syntax errors weren't
> adequately cleaned. This addresses the various errors, plus one
> minor issue with string type conversion.
>
> Signed-off-by: Aaron Conole
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1809184
Tested-by: Flavio Leitner
Acked-by: Flavio Leitner
Please apply to branch-2.13 as well.
Thanks,
fbl
> ---
>
>
> diff --git a/utilities/ovs-dpctl-top.in b/utilities/ovs-dpctl-top.in
> index f2cc3f7f2a..011cc64b74 100755
> --- a/utilities/ovs-dpctl-top.in
> +++ b/utilities/ovs-dpctl-top.in
> @@ -592,7 +592,7 @@ def flows_read(ihdl, flow_db):
>
> try:
> flow_db.flow_line_add(line)
> -except ValueError, arg:
> +except ValueError as arg:
> logging.error(arg)
>
> return flow_db
> @@ -958,6 +958,9 @@ class FlowDB:
> change order of fields of the same flow.
> """
>
> +if not isinstance(line, str):
> + line = str(line)
> +
> line = line.rstrip("\n")
> (fields, stats, _) = flow_line_split(line)
>
> @@ -988,7 +991,7 @@ class FlowDB:
>
> self.flow_event(fields_dict, stats_old_dict, stats_dict)
>
> -except ValueError, arg:
> +except ValueError as arg:
> logging.error(arg)
> self._error_count += 1
> raise
> @@ -1192,7 +1195,7 @@ def flows_top(args):
> flows_read(ihdl, flow_db)
> finally:
> ihdl.close()
> -except OSError, arg:
> +except OSError as arg:
> logging.critical(arg)
> break
>
> @@ -1220,7 +1223,7 @@ def flows_top(args):
>
> # repeat output
> for (count, line) in lines:
> -print line
> +print(line)
>
>
> def flows_script(args):
> @@ -1249,7 +1252,7 @@ def flows_script(args):
> render = Render(console_width, Render.FIELD_SELECT_SCRIPT)
>
> for line in render.format(flow_db):
> -print line
> +print(line)
>
>
> def main():
> ---
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
--
fbl
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] ovs-dpctl-top: python3 compatibility
During the transition to python3 support, some syntax errors weren't
adequately cleaned. This addresses the various errors, plus one
minor issue with string type conversion.
Signed-off-by: Aaron Conole
---
diff --git a/utilities/ovs-dpctl-top.in b/utilities/ovs-dpctl-top.in
index f2cc3f7f2a..011cc64b74 100755
--- a/utilities/ovs-dpctl-top.in
+++ b/utilities/ovs-dpctl-top.in
@@ -592,7 +592,7 @@ def flows_read(ihdl, flow_db):
try:
flow_db.flow_line_add(line)
-except ValueError, arg:
+except ValueError as arg:
logging.error(arg)
return flow_db
@@ -958,6 +958,9 @@ class FlowDB:
change order of fields of the same flow.
"""
+if not isinstance(line, str):
+ line = str(line)
+
line = line.rstrip("\n")
(fields, stats, _) = flow_line_split(line)
@@ -988,7 +991,7 @@ class FlowDB:
self.flow_event(fields_dict, stats_old_dict, stats_dict)
-except ValueError, arg:
+except ValueError as arg:
logging.error(arg)
self._error_count += 1
raise
@@ -1192,7 +1195,7 @@ def flows_top(args):
flows_read(ihdl, flow_db)
finally:
ihdl.close()
-except OSError, arg:
+except OSError as arg:
logging.critical(arg)
break
@@ -1220,7 +1223,7 @@ def flows_top(args):
# repeat output
for (count, line) in lines:
-print line
+print(line)
def flows_script(args):
@@ -1249,7 +1252,7 @@ def flows_script(args):
render = Render(console_width, Render.FIELD_SELECT_SCRIPT)
for line in render.format(flow_db):
-print line
+print(line)
def main():
---
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovsdb-idl.c: Clear conditions when clearing IDL.
On 2/29/20 12:00 AM, Dumitru Ceara wrote:
> If the ovsdb-server reply to "monitor_cond_since" requests has
> "found" == false then ovsdb_idl_db_parse_monitor_reply() calls
> ovsdb_idl_db_clear() which iterates through all tables and
> unconditionally sets table->cond_changed to false.
>
> However, if the client had already set a new condition for some of the
> tables, this new condition request will never be sent to ovsdb-server
> until the condition is reset to a different value. This is due to the
> check in ovsdb_idl_db_set_condition().
>
> In order to fix this we now also call ovsdb_idl_condition_clear() for
> each table condition in ovsdb_idl_db_clear(). This ensures that
> resetting the condition to the same value as before the
> "monitor_cond_since" reply will trigger a new request.
>
> One way to replicate the issue is described in the bugzilla reporting
> the bug, when ovn-controller is configured to use "ovn-monitor-all":
> https://bugzilla.redhat.com/show_bug.cgi?id=1808125#c6
>
> Reported-by: Dan Williams
> Reported-at: https://bugzilla.redhat.com/1808125
> CC: Han Zhou
> Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection
> reset.")
> Signed-off-by: Dumitru Ceara
Hi Han,
I was wondering if you could review this change because ovn-kubernetes
is trying to enable ovn-monitor-all for scalability reasons but their CI
fails due to the bug fixed by the patch below.
Thanks,
Dumitru
> ---
> lib/ovsdb-idl.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/lib/ovsdb-idl.c b/lib/ovsdb-idl.c
> index 190143f..64721ca 100644
> --- a/lib/ovsdb-idl.c
> +++ b/lib/ovsdb-idl.c
> @@ -610,7 +610,11 @@ ovsdb_idl_db_clear(struct ovsdb_idl_db *db)
> struct ovsdb_idl_table *table = >tables[i];
> struct ovsdb_idl_row *row, *next_row;
>
> -table->cond_changed = false;
> +if (table->cond_changed) {
> +table->cond_changed = false;
> +ovsdb_idl_condition_clear(>condition);
> +}
> +
> if (hmap_is_empty(>rows)) {
> continue;
> }
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Secretaría del Trabajo y Previsión Social
Buen día El curso tiene una nueva fecha y quise aprovechar la oportunidad de hacerte unainvitación: •Nombre: Guía paso a paso: Trámites de capacitación ante la S.T.P.S. •¿Cuándo?: Martes 10 de Marzo del 2020 •Formato: En línea con interacción en vivo. •Lugar: En Vivo desde su computadora •Instructor: Gabriela Garza En este webinar te presentamos una guía práctica paso a paso del proceso que debemos seguir ante este organismo para registrar la capacitación de nuestro personal así como la documentación necesaria para cumplir ante una supervisión o auditoría. Ofrecer una guía paso a paso de lo que la Secretaría del Trabajo y Previsión Social solicita a las empresas para registrar sus capacitaciones. Proporcionaremos las herramientas más importantes y de vanguardia que se están utilizando para medir la satisfacción de los clientes y que nos ayudarán a centrar la estrategia de nuestra organización en las necesidades de nuestro cliente. Si el tema del curso no se apega a tus necesidades podemos ayudarte con cursos privados personalizados en línea o presenciales. En este curso participan empresas de todo el país y nuestro instructor es un experto en el tema que puede atender directamente las dudas y comentarios de tu equipo de trabajo. Solicita información respondiendo a este correo con la palabra Trámites, junto con los siguientes datos: Nombre: Correo electrónico: Número telefónico: Números de Atención: (045) 55 15 54 66 30 - (045) 55 85 56 72 93 - (045) 55 30 16 70 85 Qué tengas un gran día. Saludos. Si desea dejar de recibir nuestra promoción favor de responder con la palabra baja o enviar un correo a bajas @innovalearn.net ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 ovn] manage ARP process locally in a DVR scenario
> On Mon, Mar 2, 2020 at 3:08 PM Lorenzo Bianconi
> wrote:
> >
> > OVN currently performs L2 address resolution and IP buffering on the
> > gw node. If the system relies on FIPs, OVN will re-inject the buffered
> > IP packets on the gw node, while following packets will go though
> > the localnet port on the compute node resulting in a ToR switch
> > misconfiguration. This patch addresses the issue managing ARP
> > and IP buffering locally if FIPs are configured on the node
> >
> > Signed-off-by: Lorenzo Bianconi
>
> Thanks Lorenzo. I applied this patch to master and branch-20.03 (as
> it's a pretty serious bug
> and we need the fix)
>
> I applied by adding the below test case and some modifications to
> ovn-northd.8.xml. The patch modified
> the priority of some of the existing logical flows. I updated the
> documentation accordingly.
ack, thx a lot Numan.
Regards,
Lorenzo
>
> *
> diff --git a/tests/ovn.at b/tests/ovn.at
> index 3f0fb9c18..a04f22c4c 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -9503,6 +9503,20 @@ AT_CHECK([as hv3 ovs-vsctl set Open_vSwitch .
> external-ids:ovn-bridge-mappings=p
> OVS_WAIT_UNTIL([test 1 = `as hv3 ovs-vsctl show | \
> grep "Port patch-br-int-to-ln_port" | wc -l`])
>
> +AT_CHECK([test 1 = `ovn-sbctl dump-flows lr0 | grep lr_in_ip_routing | \
> +grep "ip4.src == 10.0.0.3 && is_chassis_resident(\"foo1\")" -c`])
> +AT_CHECK([test 1 = `ovn-sbctl dump-flows lr0 | grep lr_in_ip_routing | \
> +grep "ip4.src == 10.0.0.4 && is_chassis_resident(\"foo2\")" -c`])
> +
> +key=`ovn-sbctl --bare --columns tunnel_key list datapath_Binding lr0`
> +# Check that the OVS flows appear for the dnat_and_snat entries in
> +# lr_in_ip_routing table.
> +OVS_WAIT_UNTIL([test 1 = `as hv3 ovs-ofctl dump-flows br-int table=17 | \
> +grep "priority=400,ip,metadata=0x$key,nw_src=10.0.0.3" -c`])
> +
> +OVS_WAIT_UNTIL([test 1 = `as hv3 ovs-ofctl dump-flows br-int table=17 | \
> +grep "priority=400,ip,metadata=0x$key,nw_src=10.0.0.4" -c`])
> +
> # Re-add nat-addresses option
> ovn-nbctl lsp-set-options lrp0-rp router-port=lrp0 nat-addresses="router"
>
> **
>
> Thanks
> Numan
>
> > ---
> > Changes since v2:
> > - fix memory leak in add_distributed_routes
> > - move check on logical router port before running add_distributed_routes
> >
> > Changes since v1:
> > - add comments
> > - cosmetics
> > ---
> > northd/ovn-northd.8.xml | 31
> > northd/ovn-northd.c | 53 -
> > 2 files changed, 83 insertions(+), 1 deletion(-)
> >
> > diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
> > index a27dfa951..23b385377 100644
> > --- a/northd/ovn-northd.8.xml
> > +++ b/northd/ovn-northd.8.xml
> > @@ -2405,6 +2405,37 @@ output;
> >
> >
> >
> > +
> > +
> > + For distributed logical routers where one of the logical router
> > ports
> > + specifies a redirect-chassis, a priority-400 logical
> > + flow for each dnat_and_snat NAT rules configured.
> > + These flows will allow to properly forward traffic to the
> > external
> > + connections if available and avoid sending it through the tunnel.
> > + Assuming the following NAT rule has been configured:
> > +
> > +
> > +
> > +external_ip = A;
> > +external_mac = B;
> > +logical_ip = C;
> > +
> > +
> > +
> > + the following action will be applied:
> > +
> > +
> > +
> > +ip.ttl--;
> > +reg0 = ip.dst;
> > +reg1 = A;
> > +eth.src = B;
> > +outport = router-port;
> > +next;
> > +
> > +
> > +
> > +
> >
> >
> >IPv4 routing table. For each route to IPv4 network N
> > with
> > diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
> > index 3a24d3c4f..0d43322cf 100644
> > --- a/northd/ovn-northd.c
> > +++ b/northd/ovn-northd.c
> > @@ -6972,6 +6972,8 @@ build_routing_policy_flow(struct hmap *lflows, struct
> > ovn_datapath *od,
> > ds_destroy();
> > }
> >
> > +/* default logical flow prioriry for distributed routes */
> > +#define DROUTE_PRIO 400
> > struct parsed_route {
> > struct ovs_list list_node;
> > struct v46_ip prefix;
> > @@ -7359,6 +7361,40 @@ build_ecmp_route_flow(struct hmap *lflows, struct
> > ovn_datapath *od,
> > ds_destroy();
> > }
> >
> > +static void
> > +add_distributed_routes(struct hmap *lflows, struct ovn_datapath *od)
> > +{
> > +struct ds actions = DS_EMPTY_INITIALIZER;
> > +struct ds match = DS_EMPTY_INITIALIZER;
> > +
> > +for (size_t i = 0; i < od->nbr->n_nat; i++) {
> > +const struct nbrec_nat *nat = od->nbr->nat[i];
> > +
> > +if (strcmp(nat->type, "dnat_and_snat") ||
> > +!nat->external_mac) {
> > +continue;
> > +}
> > +
> > +bool is_ipv4 = strchr(nat->logical_ip, '.') ? true : false;
> > +ds_put_format(, "ip%s.src == %s &&
> >
Re: [ovs-dev] When will the new version of OVN be released?
Hi, I received the necessary ACKs for the release today so my plan is to create the tag today. On 3/1/20 9:27 PM, shenjian...@gmail.com wrote: hi，mark， When will the new version of OVN be released? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 ovn] manage ARP process locally in a DVR scenario
On Mon, Mar 2, 2020 at 3:08 PM Lorenzo Bianconi
wrote:
>
> OVN currently performs L2 address resolution and IP buffering on the
> gw node. If the system relies on FIPs, OVN will re-inject the buffered
> IP packets on the gw node, while following packets will go though
> the localnet port on the compute node resulting in a ToR switch
> misconfiguration. This patch addresses the issue managing ARP
> and IP buffering locally if FIPs are configured on the node
>
> Signed-off-by: Lorenzo Bianconi
Thanks Lorenzo. I applied this patch to master and branch-20.03 (as
it's a pretty serious bug
and we need the fix)
I applied by adding the below test case and some modifications to
ovn-northd.8.xml. The patch modified
the priority of some of the existing logical flows. I updated the
documentation accordingly.
*
diff --git a/tests/ovn.at b/tests/ovn.at
index 3f0fb9c18..a04f22c4c 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -9503,6 +9503,20 @@ AT_CHECK([as hv3 ovs-vsctl set Open_vSwitch .
external-ids:ovn-bridge-mappings=p
OVS_WAIT_UNTIL([test 1 = `as hv3 ovs-vsctl show | \
grep "Port patch-br-int-to-ln_port" | wc -l`])
+AT_CHECK([test 1 = `ovn-sbctl dump-flows lr0 | grep lr_in_ip_routing | \
+grep "ip4.src == 10.0.0.3 && is_chassis_resident(\"foo1\")" -c`])
+AT_CHECK([test 1 = `ovn-sbctl dump-flows lr0 | grep lr_in_ip_routing | \
+grep "ip4.src == 10.0.0.4 && is_chassis_resident(\"foo2\")" -c`])
+
+key=`ovn-sbctl --bare --columns tunnel_key list datapath_Binding lr0`
+# Check that the OVS flows appear for the dnat_and_snat entries in
+# lr_in_ip_routing table.
+OVS_WAIT_UNTIL([test 1 = `as hv3 ovs-ofctl dump-flows br-int table=17 | \
+grep "priority=400,ip,metadata=0x$key,nw_src=10.0.0.3" -c`])
+
+OVS_WAIT_UNTIL([test 1 = `as hv3 ovs-ofctl dump-flows br-int table=17 | \
+grep "priority=400,ip,metadata=0x$key,nw_src=10.0.0.4" -c`])
+
# Re-add nat-addresses option
ovn-nbctl lsp-set-options lrp0-rp router-port=lrp0 nat-addresses="router"
**
Thanks
Numan
> ---
> Changes since v2:
> - fix memory leak in add_distributed_routes
> - move check on logical router port before running add_distributed_routes
>
> Changes since v1:
> - add comments
> - cosmetics
> ---
> northd/ovn-northd.8.xml | 31
> northd/ovn-northd.c | 53 -
> 2 files changed, 83 insertions(+), 1 deletion(-)
>
> diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
> index a27dfa951..23b385377 100644
> --- a/northd/ovn-northd.8.xml
> +++ b/northd/ovn-northd.8.xml
> @@ -2405,6 +2405,37 @@ output;
>
>
>
> +
> +
> + For distributed logical routers where one of the logical router
> ports
> + specifies a redirect-chassis, a priority-400 logical
> + flow for each dnat_and_snat NAT rules configured.
> + These flows will allow to properly forward traffic to the external
> + connections if available and avoid sending it through the tunnel.
> + Assuming the following NAT rule has been configured:
> +
> +
> +
> +external_ip = A;
> +external_mac = B;
> +logical_ip = C;
> +
> +
> +
> + the following action will be applied:
> +
> +
> +
> +ip.ttl--;
> +reg0 = ip.dst;
> +reg1 = A;
> +eth.src = B;
> +outport = router-port;
> +next;
> +
> +
> +
> +
>
>
>IPv4 routing table. For each route to IPv4 network N
> with
> diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
> index 3a24d3c4f..0d43322cf 100644
> --- a/northd/ovn-northd.c
> +++ b/northd/ovn-northd.c
> @@ -6972,6 +6972,8 @@ build_routing_policy_flow(struct hmap *lflows, struct
> ovn_datapath *od,
> ds_destroy();
> }
>
> +/* default logical flow prioriry for distributed routes */
> +#define DROUTE_PRIO 400
> struct parsed_route {
> struct ovs_list list_node;
> struct v46_ip prefix;
> @@ -7359,6 +7361,40 @@ build_ecmp_route_flow(struct hmap *lflows, struct
> ovn_datapath *od,
> ds_destroy();
> }
>
> +static void
> +add_distributed_routes(struct hmap *lflows, struct ovn_datapath *od)
> +{
> +struct ds actions = DS_EMPTY_INITIALIZER;
> +struct ds match = DS_EMPTY_INITIALIZER;
> +
> +for (size_t i = 0; i < od->nbr->n_nat; i++) {
> +const struct nbrec_nat *nat = od->nbr->nat[i];
> +
> +if (strcmp(nat->type, "dnat_and_snat") ||
> +!nat->external_mac) {
> +continue;
> +}
> +
> +bool is_ipv4 = strchr(nat->logical_ip, '.') ? true : false;
> +ds_put_format(, "ip%s.src == %s &&
> is_chassis_resident(\"%s\")",
> + is_ipv4 ? "4" : "6", nat->logical_ip,
> + nat->logical_port);
> +char *prefix = is_ipv4 ? "" : "xx";
> +ds_put_format(, "outport = %s; eth.src = %s; "
> + "%sreg0 = ip%s.dst; %sreg1 = %s; next;",
> +
[ovs-dev] [PATCH 1/2] dpdk: Remove deprecated pdump support.
DPDK pdump was deprecated in 2.13 release and didn't actually
work since 2.11. Removing it.
More details in commit 4ae8c4617fd3 ("dpdk: Deprecate pdump support.")
Signed-off-by: Ilya Maximets
---
.travis/linux-build.sh | 6 ---
Documentation/automake.mk | 1 -
Documentation/topics/dpdk/index.rst | 1 -
Documentation/topics/dpdk/pdump.rst | 74 -
NEWS| 2 +
acinclude.m4| 19
lib/dpdk.c | 12 -
7 files changed, 2 insertions(+), 113 deletions(-)
delete mode 100644 Documentation/topics/dpdk/pdump.rst
diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index bb47b3ee1..359f7773b 100755
--- a/.travis/linux-build.sh
+++ b/.travis/linux-build.sh
@@ -124,10 +124,6 @@ function install_dpdk()
sed -i '/CONFIG_RTE_EAL_IGB_UIO=y/s/=y/=n/' build/.config
sed -i '/CONFIG_RTE_KNI_KMOD=y/s/=y/=n/' build/.config
-# Enable pdump support in DPDK.
-sed -i '/CONFIG_RTE_LIBRTE_PMD_PCAP=n/s/=n/=y/' build/.config
-sed -i '/CONFIG_RTE_LIBRTE_PDUMP=n/s/=n/=y/' build/.config
-
make -j4 CC=gcc EXTRA_CFLAGS='-fPIC'
EXTRA_OPTS="$EXTRA_OPTS --with-dpdk=$(pwd)/build"
echo "Installed DPDK source in $(pwd)"
@@ -168,8 +164,6 @@ if [ "$DPDK" ] || [ "$DPDK_SHARED" ]; then
DPDK_VER="19.11"
fi
install_dpdk $DPDK_VER
-# Enable pdump support in OVS.
-EXTRA_OPTS="${EXTRA_OPTS} --enable-dpdk-pdump"
if [ "$CC" = "clang" ]; then
# Disregard cast alignment errors until DPDK is fixed
CFLAGS_FOR_OVS="${CFLAGS_FOR_OVS} -Wno-cast-align"
diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 22976a3cd..691f345ec 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -36,7 +36,6 @@ DOC_SOURCE = \
Documentation/topics/dpdk/bridge.rst \
Documentation/topics/dpdk/jumbo-frames.rst \
Documentation/topics/dpdk/memory.rst \
- Documentation/topics/dpdk/pdump.rst \
Documentation/topics/dpdk/phy.rst \
Documentation/topics/dpdk/pmd.rst \
Documentation/topics/dpdk/qos.rst \
diff --git a/Documentation/topics/dpdk/index.rst
b/Documentation/topics/dpdk/index.rst
index f2862ea70..336dcc56b 100644
--- a/Documentation/topics/dpdk/index.rst
+++ b/Documentation/topics/dpdk/index.rst
@@ -38,6 +38,5 @@ DPDK Support
/topics/dpdk/vdev
/topics/dpdk/pmd
/topics/dpdk/qos
- /topics/dpdk/pdump
/topics/dpdk/jumbo-frames
/topics/dpdk/memory
diff --git a/Documentation/topics/dpdk/pdump.rst
b/Documentation/topics/dpdk/pdump.rst
deleted file mode 100644
index ce03b327a..0
--- a/Documentation/topics/dpdk/pdump.rst
+++ /dev/null
@@ -1,74 +0,0 @@
-..
- Licensed under the Apache License, Version 2.0 (the "License"); you may
- not use this file except in compliance with the License. You may obtain
- a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- License for the specific language governing permissions and limitations
- under the License.
-
- Convention for heading levels in Open vSwitch documentation:
-
- === Heading 0 (reserved for the title in a document)
- --- Heading 1
- ~~~ Heading 2
- +++ Heading 3
- ''' Heading 4
-
- Avoid deeper levels because they do not render well.
-
-=
-pdump
-=
-
-.. versionadded:: 2.6.0
-
-.. warning::
-
- DPDK pdump support is deprecated in OVS and will be removed in next
- releases.
-
-pdump allows you to listen on DPDK ports and view the traffic that is passing
-on them. To use this utility, one must have libpcap installed on the system.
-Furthermore, DPDK must be built with ``CONFIG_RTE_LIBRTE_PDUMP=y`` and
-``CONFIG_RTE_LIBRTE_PMD_PCAP=y``. OVS should be built with
-``--enable-dpdk-pdump`` configuration option.
-
-.. warning::
-
- A performance decrease is expected when using a monitoring application like
- the DPDK pdump app.
-
-To use pdump, simply launch OVS as usual, then navigate to the ``app/pdump``
-directory in DPDK, ``make`` the application and run like so::
-
-$ sudo ./build/app/dpdk-pdump -- \
---pdump port=0,queue=0,rx-dev=/tmp/pkts.pcap
-
-The above command captures traffic received on queue 0 of port 0 and stores it
-in ``/tmp/pkts.pcap``. Other combinations of port numbers, queues numbers and
-pcap locations are of course also available to use. For example, to capture all
-packets that traverse port 0 in a single pcap file::
-
-$ sudo ./build/app/dpdk-pdump -- \
---pdump 'port=0,queue=*,rx-dev=/tmp/pkts.pcap,tx-dev=/tmp/pkts.pcap'
-
-.. note::
-
- ``XDG_RUNTIME_DIR`` environment
[ovs-dev] [PATCH 2/2] netdev-dpdk: Remove deprecated ring port type.
'dpdkr' ring ports was deprecated in 2.13 release and was not
actually used for a long time. Remove support now.
More details in
commit b4c5f00c339b ("netdev-dpdk: Deprecate ring ports.")
Signed-off-by: Ilya Maximets
---
Documentation/automake.mk | 1 -
Documentation/topics/dpdk/index.rst | 1 -
Documentation/topics/dpdk/ring.rst| 92
NEWS | 1 +
lib/netdev-dpdk.c | 189 -
rhel/README.RHEL.rst | 3 -
rhel/etc_sysconfig_network-scripts_ifdown-ovs | 2 +-
rhel/etc_sysconfig_network-scripts_ifup-ovs | 7 -
tests/.gitignore | 1 -
tests/automake.mk | 7 -
tests/dpdk/ring_client.c | 200 --
11 files changed, 2 insertions(+), 502 deletions(-)
delete mode 100644 Documentation/topics/dpdk/ring.rst
delete mode 100644 tests/dpdk/ring_client.c
diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 691f345ec..f85c4320e 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -39,7 +39,6 @@ DOC_SOURCE = \
Documentation/topics/dpdk/phy.rst \
Documentation/topics/dpdk/pmd.rst \
Documentation/topics/dpdk/qos.rst \
- Documentation/topics/dpdk/ring.rst \
Documentation/topics/dpdk/vdev.rst \
Documentation/topics/dpdk/vhost-user.rst \
Documentation/topics/fuzzing/index.rst \
diff --git a/Documentation/topics/dpdk/index.rst
b/Documentation/topics/dpdk/index.rst
index 336dcc56b..a5be5e344 100644
--- a/Documentation/topics/dpdk/index.rst
+++ b/Documentation/topics/dpdk/index.rst
@@ -34,7 +34,6 @@ DPDK Support
/topics/dpdk/bridge
/topics/dpdk/phy
/topics/dpdk/vhost-user
- /topics/dpdk/ring
/topics/dpdk/vdev
/topics/dpdk/pmd
/topics/dpdk/qos
diff --git a/Documentation/topics/dpdk/ring.rst
b/Documentation/topics/dpdk/ring.rst
deleted file mode 100644
index 9d91498c7..0
--- a/Documentation/topics/dpdk/ring.rst
+++ /dev/null
@@ -1,92 +0,0 @@
-..
- Licensed under the Apache License, Version 2.0 (the "License"); you may
- not use this file except in compliance with the License. You may obtain
- a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- License for the specific language governing permissions and limitations
- under the License.
-
- Convention for heading levels in Open vSwitch documentation:
-
- === Heading 0 (reserved for the title in a document)
- --- Heading 1
- ~~~ Heading 2
- +++ Heading 3
- ''' Heading 4
-
- Avoid deeper levels because they do not render well.
-
-===
-DPDK Ring Ports
-===
-
-.. warning::
-
- DPDK ring ports are considered *deprecated*. Please migrate to
- virtio-based interfaces, e.g. :doc:`vhost-user ` ports,
- ``net_virtio_user`` :doc:`DPDK vdev `.
-
-.. warning::
-
- DPDK ring interfaces cannot be used for guest communication and are retained
- mainly for backwards compatibility purposes. In nearly all cases,
- :doc:`vhost-user ports ` are a better choice and should be used
- instead.
-
-OVS userspace switching supports ring ports implemented using DPDK's
-``librte_ring`` library. For more information on this library, refer
-to the `DPDK documentation`_.
-
-.. important::
-
- To use any DPDK-backed interface, you must ensure your bridge is configured
- correctly. For more information, refer to :doc:`bridge`.
-
-Quick Example
--
-
-This example demonstrates how to add a ``dpdkr`` port to an existing bridge
-called ``br0``::
-
-$ ovs-vsctl add-port br0 dpdkr0 -- set Interface dpdkr0 type=dpdkr
-
-dpdkr
--
-
-To use ring ports, you must first add said ports to the switch. Unlike
-:doc:`vhost-user ports `, ring port names must take a specific
-format, ``dpdkrNN``, where ``NN`` is the port ID. For example::
-
-$ ovs-vsctl add-port br0 dpdkr0 -- set Interface dpdkr0 type=dpdkr
-
-Once the port has been added to the switch, they can be used by host processes.
-A sample loopback application - ``test-dpdkr`` - is included with Open vSwitch.
-To use this, run the following::
-
-$ ./tests/test-dpdkr -c 1 -n 4 --proc-type=secondary -- -n 0
-
-Further functionality would require developing your own application. Refer to
-the `DPDK documentation`_ for more information on how to do this.
-
-Adding dpdkr ports to the guest
-~~~
-
-It is **not** recommended to use ring ports from guests. Historically, this was
-possible using a patched version of QEMU and the IVSHMEM
[ovs-dev] [PATCH 0/2] dpdk: Remove deprecated pdump and dpdkr.
Ilya Maximets (2): dpdk: Remove deprecated pdump support. netdev-dpdk: Remove deprecated ring port type. .travis/linux-build.sh| 6 - Documentation/automake.mk | 2 - Documentation/topics/dpdk/index.rst | 2 - Documentation/topics/dpdk/pdump.rst | 74 --- Documentation/topics/dpdk/ring.rst| 92 NEWS | 3 + acinclude.m4 | 19 -- lib/dpdk.c| 12 -- lib/netdev-dpdk.c | 189 - rhel/README.RHEL.rst | 3 - rhel/etc_sysconfig_network-scripts_ifdown-ovs | 2 +- rhel/etc_sysconfig_network-scripts_ifup-ovs | 7 - tests/.gitignore | 1 - tests/automake.mk | 7 - tests/dpdk/ring_client.c | 200 -- 15 files changed, 4 insertions(+), 615 deletions(-) delete mode 100644 Documentation/topics/dpdk/pdump.rst delete mode 100644 Documentation/topics/dpdk/ring.rst delete mode 100644 tests/dpdk/ring_client.c -- 2.24.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] userspace-tso: Document the minimum kernel version.
On 2/28/20 11:58 PM, Flavio Leitner wrote:
> The kernel needs to be at least 4.19-rc7 to include the commit
> 9d2f67e43b73 ("net/packet: fix packet drop as of virtio gso")
> otherwise the TSO packets are dropped when using raw sockets.
>
> Fixes: 29cf9c1b3b9c ("userspace: Add TCP Segmentation Offload support")
> Reported-by: Yi Yang (杨燚)-云服务集团
> Signed-off-by: Flavio Leitner
> ---
> Documentation/topics/userspace-tso.rst | 4
> 1 file changed, 4 insertions(+)
>
> This applies to branch-2.13 as well.
>
> diff --git a/Documentation/topics/userspace-tso.rst
> b/Documentation/topics/userspace-tso.rst
> index 0fbac93a5..da370e64f 100644
> --- a/Documentation/topics/userspace-tso.rst
> +++ b/Documentation/topics/userspace-tso.rst
> @@ -113,6 +113,10 @@ __ https://patches.dpdk.org/patch/64136/
> This fix is expected to be included in the 19.11.1 release. When OVS migrates
> to this DPDK release, this limitation can be removed.
>
> +All kernel devices that use the raw socket interface (veth, for example)
> +require a kernel with minimum version of 4.19-rc7 to include the commit:
> +9d2f67e43b73 ("net/packet: fix packet drop as of virtio gso").
I'm not very happy with this kind of documentation updates. The main reason
is that every distribution uses their own custom kernel with some patches
backported or not. In this particular case we seem to have issue with
particular ubuntu kernel that happened to not have this bug fix backported.
If someone uses non-lognterm upstream kernel that is out of its support
lifetime it's his/her responsibility to backport bugfixes.
Upstream LTS kernel 4.14 has this bugfix backported and there should be
no issues. Upstream LTS 4.9 might not have this issue at all and work
fine (I didn't check).
What we can document is that particular kernel version from the Ubuntu 16.04
distribution has an issue and should not be used along with userspace-tso.
Ideally, someone should file a bug for ubuntu kernel maintainers, so they
will backport relevant patch and update their kernel since it's still in a
supported state. In this case we will have no need to document anything.
What do you think?
Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH branch-2.12] ovn-northd: Fix IP local multicast flooding.
On 2/28/20 8:20 PM, Ben Pfaff wrote:
> On Thu, Feb 27, 2020 at 10:15:59AM +0100, Dumitru Ceara wrote:
>> Skip IGMP entries learned for local multicast groups when generating
>> logical flows. We still allow ovn-controller to learn them as
>> it might be useful information for administrators to see that hosts
>> register for the groups even though they are not expected to send JOIN
>> messages for this range.
>>
>> Note: The upstream OVN master patch doesn't apply cleanly because OVN
>> 2.12 doesn't support MLD. The conflict is however easy to solve and
>> involves removing the IPv6 specific code.
>>
>> Fixes: ddc64665b678 ("OVN: Add ovn-northd IGMP support")
>> Reported-by: Lucas Alvares Gomes
>> Reported-at: https://bugzilla.redhat.com/1803008
>> Signed-off-by: Dumitru Ceara
>> Acked-by: Mark Michelson
>> (cherry picked from OVN commit 755ffada2a66416173d5f1e09672909d40f87fd1)
>
> Thanks, applied to branch-2.12.
>
Thanks Ben!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v3 ovn] manage ARP process locally in a DVR scenario
OVN currently performs L2 address resolution and IP buffering on the
gw node. If the system relies on FIPs, OVN will re-inject the buffered
IP packets on the gw node, while following packets will go though
the localnet port on the compute node resulting in a ToR switch
misconfiguration. This patch addresses the issue managing ARP
and IP buffering locally if FIPs are configured on the node
Signed-off-by: Lorenzo Bianconi
---
Changes since v2:
- fix memory leak in add_distributed_routes
- move check on logical router port before running add_distributed_routes
Changes since v1:
- add comments
- cosmetics
---
northd/ovn-northd.8.xml | 31
northd/ovn-northd.c | 53 -
2 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index a27dfa951..23b385377 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -2405,6 +2405,37 @@ output;
+
+
+ For distributed logical routers where one of the logical router ports
+ specifies a redirect-chassis, a priority-400 logical
+ flow for each dnat_and_snat NAT rules configured.
+ These flows will allow to properly forward traffic to the external
+ connections if available and avoid sending it through the tunnel.
+ Assuming the following NAT rule has been configured:
+
+
+
+external_ip = A;
+external_mac = B;
+logical_ip = C;
+
+
+
+ the following action will be applied:
+
+
+
+ip.ttl--;
+reg0 = ip.dst;
+reg1 = A;
+eth.src = B;
+outport = router-port;
+next;
+
+
+
+
IPv4 routing table. For each route to IPv4 network N with
diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index 3a24d3c4f..0d43322cf 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -6972,6 +6972,8 @@ build_routing_policy_flow(struct hmap *lflows, struct
ovn_datapath *od,
ds_destroy();
}
+/* default logical flow prioriry for distributed routes */
+#define DROUTE_PRIO 400
struct parsed_route {
struct ovs_list list_node;
struct v46_ip prefix;
@@ -7359,6 +7361,40 @@ build_ecmp_route_flow(struct hmap *lflows, struct
ovn_datapath *od,
ds_destroy();
}
+static void
+add_distributed_routes(struct hmap *lflows, struct ovn_datapath *od)
+{
+struct ds actions = DS_EMPTY_INITIALIZER;
+struct ds match = DS_EMPTY_INITIALIZER;
+
+for (size_t i = 0; i < od->nbr->n_nat; i++) {
+const struct nbrec_nat *nat = od->nbr->nat[i];
+
+if (strcmp(nat->type, "dnat_and_snat") ||
+!nat->external_mac) {
+continue;
+}
+
+bool is_ipv4 = strchr(nat->logical_ip, '.') ? true : false;
+ds_put_format(, "ip%s.src == %s && is_chassis_resident(\"%s\")",
+ is_ipv4 ? "4" : "6", nat->logical_ip,
+ nat->logical_port);
+char *prefix = is_ipv4 ? "" : "xx";
+ds_put_format(, "outport = %s; eth.src = %s; "
+ "%sreg0 = ip%s.dst; %sreg1 = %s; next;",
+ od->l3dgw_port->json_key, nat->external_mac,
+ prefix, is_ipv4 ? "4" : "6",
+ prefix, nat->external_ip);
+ovn_lflow_add(lflows, od, S_ROUTER_IN_IP_ROUTING, DROUTE_PRIO,
+ ds_cstr(), ds_cstr());
+ds_clear();
+ds_clear();
+}
+
+ds_destroy();
+ds_destroy();
+}
+
static void
add_route(struct hmap *lflows, const struct ovn_port *op,
const char *lrp_addr_s, const char *network_s, int plen,
@@ -7380,6 +7416,12 @@ add_route(struct hmap *lflows, const struct ovn_port *op,
}
build_route_match(op_inport, network_s, plen, is_src_route, is_ipv4,
, );
+/* traffic for internal IPs of logical switch ports must be sent to
+ * the gw controller through the overlay tunnels
+ */
+if (op->nbrp && !op->nbrp->n_gateway_chassis) {
+priority += DROUTE_PRIO;
+}
struct ds actions = DS_EMPTY_INITIALIZER;
ds_put_format(, "ip.ttl--; "REG_ECMP_GROUP_ID" = 0; %sreg0 = ",
@@ -8948,7 +8990,7 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap
*ports,
nat->logical_ip,
od->l3dgw_port->json_key);
ovn_lflow_add_with_hint(lflows, od, S_ROUTER_IN_GW_REDIRECT,
-100, ds_cstr(), "next;",
+200, ds_cstr(), "next;",
>header_);
}
@@ -9229,6 +9271,15 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap
*ports,
ovn_lflow_add(lflows, od, S_ROUTER_IN_ND_RA_RESPONSE, 0, "1", "next;");
}
+/* Logical router ingress table IP_ROUTING - IP routing for distributed
+ * logical router
+ */
+
Re: [ovs-dev] [PATCH v2 ovn] manage ARP process locally in a DVR scenario
> On Thu, Feb 27, 2020 at 11:21 PM Lorenzo Bianconi
> wrote:
> >
> > OVN currently performs L2 address resolution and IP buffering on the
> > gw node. If the system relies on FIPs, OVN will re-inject the buffered
> > IP packets on the gw node, while following packets will go though
> > the localnet port on the compute node resulting in a ToR switch
> > misconfiguration. This patch addresses the issue managing ARP
> > and IP buffering locally if FIPs are configured on the node
> >
> > Signed-off-by: Lorenzo Bianconi
> > ---
> > Changes since v1:
> > - add comments
> > - cosmetics
> > ---
> > northd/ovn-northd.8.xml | 31
> > northd/ovn-northd.c | 52 -
> > 2 files changed, 82 insertions(+), 1 deletion(-)
> >
> > diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
> > index a27dfa951..23b385377 100644
> > --- a/northd/ovn-northd.8.xml
> > +++ b/northd/ovn-northd.8.xml
> > @@ -2405,6 +2405,37 @@ output;
> >
> >
> >
> > +
> > +
> > + For distributed logical routers where one of the logical router
> > ports
> > + specifies a redirect-chassis, a priority-400 logical
> > + flow for each dnat_and_snat NAT rules configured.
> > + These flows will allow to properly forward traffic to the
> > external
> > + connections if available and avoid sending it through the tunnel.
> > + Assuming the following NAT rule has been configured:
> > +
> > +
> > +
> > +external_ip = A;
> > +external_mac = B;
> > +logical_ip = C;
> > +
> > +
> > +
> > + the following action will be applied:
> > +
> > +
> > +
> > +ip.ttl--;
> > +reg0 = ip.dst;
> > +reg1 = A;
> > +eth.src = B;
> > +outport = router-port;
> > +next;
> > +
> > +
> > +
> > +
> >
> >
> >IPv4 routing table. For each route to IPv4 network N
> > with
> > diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
> > index d007ba610..53958b26b 100644
> > --- a/northd/ovn-northd.c
> > +++ b/northd/ovn-northd.c
> > @@ -6967,6 +6967,8 @@ build_routing_policy_flow(struct hmap *lflows, struct
> > ovn_datapath *od,
> > ds_destroy();
> > }
> >
> > +/* default logical flow prioriry for distributed routes */
> > +#define DROUTE_PRIO 400
> > struct parsed_route {
> > struct ovs_list list_node;
> > struct v46_ip prefix;
> > @@ -7354,6 +7356,41 @@ build_ecmp_route_flow(struct hmap *lflows, struct
> > ovn_datapath *od,
> > ds_destroy();
> > }
> >
> > +static void
> > +add_distributed_routes(struct hmap *lflows, struct ovn_datapath *od)
> > +{
> > +struct ds actions = DS_EMPTY_INITIALIZER;
> > +struct ds match = DS_EMPTY_INITIALIZER;
> > +
> > +if (!od->l3dgw_port || !od->nbr) {
> > +return;
> > +}
> > +
> > +for (size_t i = 0; i < od->nbr->n_nat; i++) {
> > +const struct nbrec_nat *nat = od->nbr->nat[i];
> > +
> > +if (strcmp(nat->type, "dnat_and_snat") ||
> > +!nat->external_mac) {
> > +continue;
> > +}
> > +
> > +bool is_ipv4 = strchr(nat->logical_ip, '.') ? true : false;
> > +ds_put_format(, "ip%s.src == %s &&
> > is_chassis_resident(\"%s\")",
> > + is_ipv4 ? "4" : "6", nat->logical_ip,
> > + nat->logical_port);
> > +char *prefix = is_ipv4 ? "" : "xx";
> > +ds_put_format(, "outport = %s; eth.src = %s; "
> > + "%sreg0 = ip%s.dst; %sreg1 = %s; next;",
> > + od->l3dgw_port->json_key, nat->external_mac,
> > + prefix, is_ipv4 ? "4" : "6",
> > + prefix, nat->external_ip);
> > +ovn_lflow_add(lflows, od, S_ROUTER_IN_IP_ROUTING, DROUTE_PRIO,
> > + ds_cstr(), ds_cstr());
> > +ds_clear();
> > +ds_clear();
> > +}
>
> You need to ds_destroy match and actions, otherwise there'll be a memory leak,
Hi Numan,
Thx for the review.
ack, I will fix it in v3
>
>
> > +}
> > +
> > static void
> > add_route(struct hmap *lflows, const struct ovn_port *op,
> >const char *lrp_addr_s, const char *network_s, int plen,
> > @@ -7375,6 +7412,12 @@ add_route(struct hmap *lflows, const struct ovn_port
> > *op,
> > }
> > build_route_match(op_inport, network_s, plen, is_src_route, is_ipv4,
> >, );
> > +/* traffic for internal IPs of logical switch ports must me sent to
> s/me/be
>
> > + * the gw controller through the overlay tunnels
> > + */
> > +if (op->nbrp && !op->nbrp->n_gateway_chassis) {
> > +priority += DROUTE_PRIO;
> > +}
> >
> > struct ds actions = DS_EMPTY_INITIALIZER;
> > ds_put_format(, "ip.ttl--; "REG_ECMP_GROUP_ID" = 0; %sreg0 = ",
> > @@ -8943,7 +8986,7 @@ build_lrouter_flows(struct hmap *datapaths, struct
> > hmap *ports,
> >
Re: [ovs-dev] Creation of network using ovs in Docker
Hi, I have the same issue, My ovs and ovn versions are 2.10.2 I want to connect my two docker containers using OVS-DPDK. Dpdk version: 17.11.9 root@ubuntu:~# docker network create -d openvswitch --subnet=192.168.88.0/24 ovs Error response from daemon: remote: create_network: ls-add Fatal error executing ['ovn-nbctl', '--timeout=5', '-vconsole:off', '--db=tcp::6641', 'ls-add', u'405196be7ffe4150cdc5215729c4f9efeed3d796406800f953fdfa9205569e13', '--', 'set', 'Logical_Switch', u'405196be7ffe4150cdc5215729c4f9efeed3d796406800f953fdfa9205569e13', u'external_ids:subnet=192.168.88.0/24', u'external_ids:gateway_ip=192.168.88.1'] Sent from Mail for Windows 10 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
