Re: [ovs-dev] [PATCHv11] netdev-afxdp: add new netdev type for AF_XDP.
> > > + ethtool -L enp2s0 combined 1 > > > + ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x10 > > > + ovs-vsctl add-port br0 enp2s0 -- set interface enp2s0 type="afxdp" > > > \ > > > +options:n_rxq=1 options:xdpmode=drv \ > > > +other_config:pmd-rxq-affinity="0:4" another feature I'm thinking about to add is a new options for loading custom XDP program For example: ovs-vsctl add-port br0 enp2s0 -- set interface enp2s0 type="afxdp" options:n_rxq=1 options:xdpmode=drv options:xdp_prog=/path/to/xdp.o If users do not specify the path, then it is using the libbpf's default program (which forwards all packets to userspace) If users want to use their own xdp object, then this option can load the xdp object file from the path. William ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] AF_XDP with QoS support question
Hi, When using AF_XDP, the TC qdisc layer is by-passed and packets go to userspace directly. One problem is that there is no QoS support when using AF_XDP. For egress shaping, I'm thinking about using tc-mqprio, which has hardware offload support. And for OVS, we can add tc-mqprio support. For ingress policing, I don't know how to do it. Is there an hardware offload ingress policing support? Thanks William ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofproto-dpif-xlate: Report DHCP output actions in trace.
Thanks, applied to master. On Fri, Jun 07, 2019 at 03:34:04PM -0700, Yifeng Sun wrote: > Look good to me, thanks. > > Reviewed-by: Yifeng Sun > > On Fri, Jun 7, 2019 at 1:03 PM 0-day Robot wrote: > > > > Bleep bloop. Greetings Ben Pfaff, 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. > > > > > > checkpatch: > > WARNING: Line is 88 characters long (recommended limit is 79) > > #17 FILE: ofproto/ofproto-dpif-xlate.c:1: > > /* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2019 > > Nicira, Inc. > > > > Lines checked: 32, Warnings: 1, Errors: 0 > > > > > > 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 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofproto-dpif-xlate: Do not use zero-weight buckets in select groups.
On Fri, Jun 07, 2019 at 04:27:32PM -0700, Ben Pfaff wrote: > The OpenFlow specification says that buckets in select groups with a weight > of zero should not be selected, but the ofproto-dpif implementation could > select them in corner cases. This fixes the problem. > > Reported-by: ychen > Reported-at: > https://mail.openvswitch.org/pipermail/ovs-dev/2019-May/359349.html > Signed-off-by: Ben Pfaff Ignore this, I sent a proper v2. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofproto-dpif-xlate: Do not use zero-weight buckets in select groups.
I sent v2: https://mail.openvswitch.org/pipermail/ovs-dev/2019-June/359582.html On Fri, Jun 07, 2019 at 03:55:36PM -0700, Ben Pfaff wrote: > Weights are significant only for "select" groups; > group_first_live_bucket() is used to pick a bucket only for > "fast-failover" groups. So I think that this is correct for group > selection now. > > However, group_is_alive() also uses group_first_live_bucket() for > determining whether a group is alive, and for that purpose it should > consider the group type whereas currently it just treats every group as > if it was a fast-failover group. > > I'll fix that and send a v2. > > On Fri, Jun 07, 2019 at 03:27:28PM -0700, Yifeng Sun wrote: > > Hi Ben, > > > > group_first_live_bucket() can still return zero-weighted bucket, then > > this bucket will > > be used via pick_ff_group() and xlate_group_action__(). I am wondering > > if it is an > > issue? > > > > Thanks, > > Yifeng > > > > On Fri, Jun 7, 2019 at 12:04 PM 0-day Robot wrote: > > > > > > Bleep bloop. Greetings Ben Pfaff, 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. > > > > > > > > > checkpatch: > > > WARNING: Line is 88 characters long (recommended limit is 79) > > > #23 FILE: ofproto/ofproto-dpif-xlate.c:1: > > > /* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, > > > 2019 Nicira, Inc. > > > > > > Lines checked: 47, Warnings: 1, Errors: 0 > > > > > > > > > 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 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2] ofproto-dpif-xlate: Do not use zero-weight buckets in select groups.
The OpenFlow specification says that buckets in select groups with a weight
of zero should not be selected, but the ofproto-dpif implementation could
select them in corner cases. This fixes the problem.
Reported-by: ychen
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2019-May/359349.html
Signed-off-by: Ben Pfaff
---
v1->v2: Simplify and fix figuring out whether a group is alive.
ofproto/ofproto-dpif-xlate.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 04d69ed06c20..1ace92d22019 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017 Nicira,
Inc.
+/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2019
Nicira, Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -1864,8 +1864,8 @@ group_is_alive(const struct xlate_ctx *ctx, uint32_t
group_id, int depth)
#define MAX_LIVENESS_RECURSION 128 /* Arbitrary limit */
static bool
-bucket_is_alive(const struct xlate_ctx *ctx,
-struct ofputil_bucket *bucket, int depth)
+bucket_is_alive(const struct xlate_ctx *ctx, const struct group_dpif *group,
+const struct ofputil_bucket *bucket, int depth)
{
if (depth >= MAX_LIVENESS_RECURSION) {
xlate_report_error(ctx, "bucket chaining exceeded %d links",
@@ -1873,6 +1873,12 @@ bucket_is_alive(const struct xlate_ctx *ctx,
return false;
}
+/* In "select" groups, buckets with weight 0 are not used.
+ * In other kinds of groups, weight does not matter. */
+if (group->up.type == OFPGT11_SELECT && bucket->weight == 0) {
+return false;
+}
+
return (!ofputil_bucket_has_liveness(bucket)
|| (bucket->watch_port != OFPP_ANY
&& odp_port_is_alive(ctx, bucket->watch_port))
@@ -1910,7 +1916,7 @@ group_first_live_bucket(const struct xlate_ctx *ctx,
{
struct ofputil_bucket *bucket;
LIST_FOR_EACH (bucket, list_node, >up.buckets) {
-if (bucket_is_alive(ctx, bucket, depth)) {
+if (bucket_is_alive(ctx, group, bucket, depth)) {
return bucket;
}
xlate_report_bucket_not_live(ctx, bucket);
@@ -1929,7 +1935,7 @@ group_best_live_bucket(const struct xlate_ctx *ctx,
struct ofputil_bucket *bucket;
LIST_FOR_EACH (bucket, list_node, >up.buckets) {
-if (bucket_is_alive(ctx, bucket, 0)) {
+if (bucket_is_alive(ctx, group, bucket, 0)) {
uint32_t score =
(hash_int(bucket->bucket_id, basis) & 0x) * bucket->weight;
if (score >= best_score) {
@@ -4535,7 +4541,7 @@ pick_dp_hash_select_group(struct xlate_ctx *ctx, struct
group_dpif *group)
for (int i = 0; i <= hash_mask; i++) {
struct ofputil_bucket *b =
group->hash_map[(dp_hash + i) & hash_mask];
-if (bucket_is_alive(ctx, b, 0)) {
+if (bucket_is_alive(ctx, group, b, 0)) {
return b;
}
}
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] ofproto-dpif-xlate: Do not use zero-weight buckets in select groups.
The OpenFlow specification says that buckets in select groups with a weight
of zero should not be selected, but the ofproto-dpif implementation could
select them in corner cases. This fixes the problem.
Reported-by: ychen
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2019-May/359349.html
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-xlate.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 04d69ed06c20..1ace92d22019 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017 Nicira,
Inc.
+/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2019
Nicira, Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -1864,8 +1864,8 @@ group_is_alive(const struct xlate_ctx *ctx, uint32_t
group_id, int depth)
#define MAX_LIVENESS_RECURSION 128 /* Arbitrary limit */
static bool
-bucket_is_alive(const struct xlate_ctx *ctx,
-struct ofputil_bucket *bucket, int depth)
+bucket_is_alive(const struct xlate_ctx *ctx, const struct group_dpif *group,
+const struct ofputil_bucket *bucket, int depth)
{
if (depth >= MAX_LIVENESS_RECURSION) {
xlate_report_error(ctx, "bucket chaining exceeded %d links",
@@ -1873,6 +1873,12 @@ bucket_is_alive(const struct xlate_ctx *ctx,
return false;
}
+/* In "select" groups, buckets with weight 0 are not used.
+ * In other kinds of groups, weight does not matter. */
+if (group->up.type == OFPGT11_SELECT && bucket->weight == 0) {
+return false;
+}
+
return (!ofputil_bucket_has_liveness(bucket)
|| (bucket->watch_port != OFPP_ANY
&& odp_port_is_alive(ctx, bucket->watch_port))
@@ -1910,7 +1916,7 @@ group_first_live_bucket(const struct xlate_ctx *ctx,
{
struct ofputil_bucket *bucket;
LIST_FOR_EACH (bucket, list_node, >up.buckets) {
-if (bucket_is_alive(ctx, bucket, depth)) {
+if (bucket_is_alive(ctx, group, bucket, depth)) {
return bucket;
}
xlate_report_bucket_not_live(ctx, bucket);
@@ -1929,7 +1935,7 @@ group_best_live_bucket(const struct xlate_ctx *ctx,
struct ofputil_bucket *bucket;
LIST_FOR_EACH (bucket, list_node, >up.buckets) {
-if (bucket_is_alive(ctx, bucket, 0)) {
+if (bucket_is_alive(ctx, group, bucket, 0)) {
uint32_t score =
(hash_int(bucket->bucket_id, basis) & 0x) * bucket->weight;
if (score >= best_score) {
@@ -4535,7 +4541,7 @@ pick_dp_hash_select_group(struct xlate_ctx *ctx, struct
group_dpif *group)
for (int i = 0; i <= hash_mask; i++) {
struct ofputil_bucket *b =
group->hash_map[(dp_hash + i) & hash_mask];
-if (bucket_is_alive(ctx, b, 0)) {
+if (bucket_is_alive(ctx, group, b, 0)) {
return b;
}
}
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofproto-dpif-xlate: Do not use zero-weight buckets in select groups.
Weights are significant only for "select" groups; group_first_live_bucket() is used to pick a bucket only for "fast-failover" groups. So I think that this is correct for group selection now. However, group_is_alive() also uses group_first_live_bucket() for determining whether a group is alive, and for that purpose it should consider the group type whereas currently it just treats every group as if it was a fast-failover group. I'll fix that and send a v2. On Fri, Jun 07, 2019 at 03:27:28PM -0700, Yifeng Sun wrote: > Hi Ben, > > group_first_live_bucket() can still return zero-weighted bucket, then > this bucket will > be used via pick_ff_group() and xlate_group_action__(). I am wondering > if it is an > issue? > > Thanks, > Yifeng > > On Fri, Jun 7, 2019 at 12:04 PM 0-day Robot wrote: > > > > Bleep bloop. Greetings Ben Pfaff, 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. > > > > > > checkpatch: > > WARNING: Line is 88 characters long (recommended limit is 79) > > #23 FILE: ofproto/ofproto-dpif-xlate.c:1: > > /* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2019 > > Nicira, Inc. > > > > Lines checked: 47, Warnings: 1, Errors: 0 > > > > > > 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 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] rhel: Fixed a bug for checking the correct major version and revision.
On 6/7/2019 3:39 PM, Ashish Varma wrote:
Fixed a bug where checking for major version 3.10 and major revision not
equal to 327 or 693 or 957 should have gone to the default else at the end.
In the current code, the default else condition will not get executed
for kernel with major version 3.10 and major revision not equal
to 327/693/957 resulting in failure to load the kernel module.
Signed-off-by: Ashish Varma
---
Should there be a fixes tag?
- Greg
rhel/openvswitch-kmod-fedora.spec.in | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/rhel/openvswitch-kmod-fedora.spec.in
b/rhel/openvswitch-kmod-fedora.spec.in
index 92d763f..27f443a 100644
--- a/rhel/openvswitch-kmod-fedora.spec.in
+++ b/rhel/openvswitch-kmod-fedora.spec.in
@@ -90,13 +90,12 @@ if grep -qs "suse" /etc/os-release; then
if [ -x "%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh" ]; then
%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh
fi
-elif [ "$mainline_major" = "3" ] && [ "$mainline_minor" = "10" ]; then
-if [ "$major_rev" = "327" ] || [ "$major_rev" = "693" ] || \
- [ "$major_rev" = "957" ]; then
-# For RHEL 7.2, 7.4 and 7.6
-if [ -x "%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh" ]; then
-%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh
-fi
+elif [ "$mainline_major" = "3" ] && [ "$mainline_minor" = "10" ] &&
+ { [ "$major_rev" = "327" ] || [ "$major_rev" = "693" ] || \
+ [ "$major_rev" = "957" ]; }; then
+# For RHEL 7.2, 7.4 and 7.6
+if [ -x "%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh" ]; then
+%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh
fi
else
# Ensure that modprobe will find our modules.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] rhel: Fixed a bug for checking the correct major version and revision.
Thanks Ashish for the fix.
Reviewed-by: Yifeng Sun
On Fri, Jun 7, 2019 at 3:45 PM Ashish Varma wrote:
>
> Fixed a bug where checking for major version 3.10 and major revision not
> equal to 327 or 693 or 957 should have gone to the default else at the end.
> In the current code, the default else condition will not get executed
> for kernel with major version 3.10 and major revision not equal
> to 327/693/957 resulting in failure to load the kernel module.
>
> Signed-off-by: Ashish Varma
> ---
> rhel/openvswitch-kmod-fedora.spec.in | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/rhel/openvswitch-kmod-fedora.spec.in
> b/rhel/openvswitch-kmod-fedora.spec.in
> index 92d763f..27f443a 100644
> --- a/rhel/openvswitch-kmod-fedora.spec.in
> +++ b/rhel/openvswitch-kmod-fedora.spec.in
> @@ -90,13 +90,12 @@ if grep -qs "suse" /etc/os-release; then
> if [ -x "%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh" ]; then
> %{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh
> fi
> -elif [ "$mainline_major" = "3" ] && [ "$mainline_minor" = "10" ]; then
> -if [ "$major_rev" = "327" ] || [ "$major_rev" = "693" ] || \
> - [ "$major_rev" = "957" ]; then
> -# For RHEL 7.2, 7.4 and 7.6
> -if [ -x "%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh" ]; then
> -%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh
> -fi
> +elif [ "$mainline_major" = "3" ] && [ "$mainline_minor" = "10" ] &&
> + { [ "$major_rev" = "327" ] || [ "$major_rev" = "693" ] || \
> + [ "$major_rev" = "957" ]; }; then
> +# For RHEL 7.2, 7.4 and 7.6
> +if [ -x "%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh" ]; then
> +%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh
> fi
> else
> # Ensure that modprobe will find our modules.
> --
> 2.7.4
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] rhel: Fixed a bug for checking the correct major version and revision.
Fixed a bug where checking for major version 3.10 and major revision not
equal to 327 or 693 or 957 should have gone to the default else at the end.
In the current code, the default else condition will not get executed
for kernel with major version 3.10 and major revision not equal
to 327/693/957 resulting in failure to load the kernel module.
Signed-off-by: Ashish Varma
---
rhel/openvswitch-kmod-fedora.spec.in | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/rhel/openvswitch-kmod-fedora.spec.in
b/rhel/openvswitch-kmod-fedora.spec.in
index 92d763f..27f443a 100644
--- a/rhel/openvswitch-kmod-fedora.spec.in
+++ b/rhel/openvswitch-kmod-fedora.spec.in
@@ -90,13 +90,12 @@ if grep -qs "suse" /etc/os-release; then
if [ -x "%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh" ]; then
%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh
fi
-elif [ "$mainline_major" = "3" ] && [ "$mainline_minor" = "10" ]; then
-if [ "$major_rev" = "327" ] || [ "$major_rev" = "693" ] || \
- [ "$major_rev" = "957" ]; then
-# For RHEL 7.2, 7.4 and 7.6
-if [ -x "%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh" ]; then
-%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh
-fi
+elif [ "$mainline_major" = "3" ] && [ "$mainline_minor" = "10" ] &&
+ { [ "$major_rev" = "327" ] || [ "$major_rev" = "693" ] || \
+ [ "$major_rev" = "957" ]; }; then
+# For RHEL 7.2, 7.4 and 7.6
+if [ -x "%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh" ]; then
+%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh
fi
else
# Ensure that modprobe will find our modules.
--
2.7.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofproto-dpif-xlate: Report DHCP output actions in trace.
Look good to me, thanks. Reviewed-by: Yifeng Sun On Fri, Jun 7, 2019 at 1:03 PM 0-day Robot wrote: > > Bleep bloop. Greetings Ben Pfaff, 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. > > > checkpatch: > WARNING: Line is 88 characters long (recommended limit is 79) > #17 FILE: ofproto/ofproto-dpif-xlate.c:1: > /* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2019 > Nicira, Inc. > > Lines checked: 32, Warnings: 1, Errors: 0 > > > 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 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofproto-dpif-xlate: Do not use zero-weight buckets in select groups.
Hi Ben, group_first_live_bucket() can still return zero-weighted bucket, then this bucket will be used via pick_ff_group() and xlate_group_action__(). I am wondering if it is an issue? Thanks, Yifeng On Fri, Jun 7, 2019 at 12:04 PM 0-day Robot wrote: > > Bleep bloop. Greetings Ben Pfaff, 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. > > > checkpatch: > WARNING: Line is 88 characters long (recommended limit is 79) > #23 FILE: ofproto/ofproto-dpif-xlate.c:1: > /* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2019 > Nicira, Inc. > > Lines checked: 47, Warnings: 1, Errors: 0 > > > 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 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v10] Improved Packet Drop Statistics in OVS
On 6/7/2019 2:31 PM, Gregory Rose wrote:
On 6/6/2019 10:27 PM, Anju Thomas wrote:
Currently OVS maintains explicit packet drop/error counters only on
port level.
Packets that are dropped as part of normal OpenFlow processing are
counted in flow stats of “drop” flows or as table misses in table stats.
These can only be interpreted by controllers that know the semantics
of the configured OpenFlow pipeline. Without that knowledge, it is
impossible for an OVS user to obtain e.g. the total number of packets
dropped due to OpenFlow rules.
Furthermore, there are numerous other reasons for which packets can
be dropped by OVS slow path that are not related to the OpenFlow
pipeline.
The generated datapath flow entries include a drop action to avoid
further expensive upcalls to the slow path, but subsequent packets
dropped by the datapath are not accounted anywhere.
Finally, the datapath itself drops packets in certain error situations.
Also, these drops are today not accounted for.
This makes it difficult for OVS users to monitor packet drop in an
OVS instance and to alert a management system in case of a unexpected
increase of such drops. Also OVS trouble-shooters face difficulties
in analysing packet drops.
With this patch we implement following changes to address the issues
mentioned above.
1. Identify and account all the silent packet drop scenarios
2. Display these drops in ovs-appctl coverage/show
A detailed presentation on this was presented at OvS conference 2017
and link for the corresponding presentation is available at:
https://www.slideshare.net/LF_OpenvSwitch/lfovs17troubleshooting-the-data-plane-in-ovs-82280329
Co-authored-by: Rohith Basavaraja
Co-authored-by: Keshav Gupta
Signed-off-by: Anju Thomas
Signed-off-by: Rohith Basavaraja
Signed-off-by: Keshav Gupta
Hi Anju et al,
I am going to review and test this patch, however, I do have a request
just below...
I attempted to apply the patch and got the following errors:
Applying patch #568 using 'git am'
Description: [ovs-dev,v10] Improved Packet Drop Statistics in OVS
Applying: Improved Packet Drop Statistics in OVS
error: patch failed: tests/automake.mk:109
error: tests/automake.mk: patch does not apply
/home/gvrose/prj/ovs-experimental/.git/rebase-apply/patch:804: new blank
line at EOF.
+
Patch failed at 0001 Improved Packet Drop Statistics in OVS
The copy of the patch that failed is found in:
/home/gvrose/prj/ovs-experimental/.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".
'git am' failed with exit status 1
Please rebase to current master and I can give it another try.
Thanks,
- Greg
---
Here, below the three dash line just above, there should be an
accounting of all changes from version 1 of
this patch set to version 10. Something like this:
v9 -> v10 Changed something due to review comments etc...
v8 -> v9 Describe changes from v8 to v9 etc...
I think it's essential to reviewers to understand the previous patches
and their evolution to the current patch.
Thanks,
- Greg
datapath/linux/compat/include/linux/openvswitch.h | 1 +
lib/dpif-netdev.c | 46 -
lib/dpif.c | 7 +
lib/dpif.h | 4 +
lib/odp-execute.c | 78
lib/odp-util.c | 9 +
ofproto/ofproto-dpif-ipfix.c | 1 +
ofproto/ofproto-dpif-sflow.c | 1 +
ofproto/ofproto-dpif-xlate.c | 34 +++-
ofproto/ofproto-dpif-xlate.h | 3 +
ofproto/ofproto-dpif.c | 7 +
ofproto/ofproto-dpif.h | 8 +-
tests/automake.mk | 3 +-
tests/dpif-netdev.at | 8 +
tests/drop-stats.at | 211
++
tests/ofproto-dpif.at | 2 +-
tests/tunnel-push-pop.at | 29 ++-
tests/tunnel.at | 14 +-
18 files changed, 455 insertions(+), 11 deletions(-)
create mode 100644 tests/drop-stats.at
diff --git a/datapath/linux/compat/include/linux/openvswitch.h
b/datapath/linux/compat/include/linux/openvswitch.h
index 65a003a..2de702e 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -985,6 +985,7 @@ enum ovs_action_attr {
OVS_ACTION_ATTR_METER, /* u32 meter number. */
OVS_ACTION_ATTR_CLONE, /* Nested OVS_CLONE_ATTR_*. */
OVS_ACTION_ATTR_CHECK_PKT_LEN, /* Nested
OVS_CHECK_PKT_LEN_ATTR_*. */
+ OVS_ACTION_ATTR_DROP,
#ifndef
Re: [ovs-dev] [PATCHv11] netdev-afxdp: add new netdev type for AF_XDP.
Hi Eelco,
Thanks for the testing.
On Fri, Jun 7, 2019 at 8:43 AM Eelco Chaudron wrote:
>
> Hi William,
>
> No review or full test yet, just some observations…
>
> We run OVS as a non root user, which is causing OVS with XDP to fail:
Right, XDP requires using root privilege.
I will add this in the documentation.
>
> 2019-06-07T09:14:20.628Z|00023|ofproto_dpif|INFO|netdev@ovs-netdev:
> Datapath supports ct_orig_tuple
> 2019-06-07T09:14:20.628Z|00024|ofproto_dpif|INFO|netdev@ovs-netdev:
> Datapath supports ct_orig_tuple6
> 2019-06-07T09:14:20.664Z|00025|dpif_netdev|INFO|PMD thread on numa_id:
> 0, core id: 21 created.
> 2019-06-07T09:14:20.664Z|00026|dpif_netdev|INFO|There are 1 pmd threads
> on numa node 0
> 2019-06-07T09:14:20.664Z|00027|netdev_afxdp|INFO|remove xdp program
> 2019-06-07T09:14:20.664Z|00028|netdev_afxdp|INFO|AF_XDP device eno1 in
> DRV mode
> 2019-06-07T09:14:20.664Z|00029|netdev_afxdp|ERR|ERROR:
> setrlimit(RLIMIT_MEMLOCK): Operation not permitted
This is due to not having root privilege, so not able to lock the memory
for device driver to directly DMA packet buffer into userspace.
Can you try using root?
Regards,
William
> 2019-06-07T09:14:20.664Z|00030|netdev_afxdp|INFO|xsk_configure_all
> configure queue 0 mode DRV
> 2019-06-07T09:14:20.672Z|00031|netdev_afxdp|ERR|xsk_socket__create
> failed (Operation not permitted) mode: DRV qid: 0
> 2019-06-07T09:14:20.686Z|00032|netdev_afxdp|ERR|failed to create AF_XDP
> socket on queue 0
> 2019-06-07T09:14:20.686Z|00033|netdev_afxdp|INFO|remove xdp program
> 2019-06-07T09:14:20.687Z|00034|netdev_afxdp|ERR|AF_XDP device eno1
> reconfig fails
> 2019-06-07T09:14:20.687Z|00035|dpif_netdev|ERR|Failed to set interface
> eno1 new configuration
>
> However when configuring this after startup it’s fine, but trying to
> restart OVS with this configuration results in a system core…
>
>
>
>
> On 5 Jun 2019, at 22:47, William Tu wrote:
>
> > The patch introduces experimental AF_XDP support for OVS netdev.
> > AF_XDP, the Address Family of the eXpress Data Path, is a new Linux
> > socket
> > type built upon the eBPF and XDP technology. It is aims to have
> > comparable
> > performance to DPDK but cooperate better with existing kernel's
> > networking
> > stack. An AF_XDP socket receives and sends packets from an eBPF/XDP
> > program
> > attached to the netdev, by-passing a couple of Linux kernel's
> > subsystems
> > As a result, AF_XDP socket shows much better performance than
> > AF_PACKET
> > For more details about AF_XDP, please see linux kernel's
> > Documentation/networking/af_xdp.rst. Note that by default, this
> > feature is
> > not compiled in.
> >
> > Signed-off-by: William Tu
> > ---
> > v1->v2:
> > - add a list to maintain unused umem elements
> > - remove copy from rx umem to ovs internal buffer
> > - use hugetlb to reduce misses (not much difference)
> > - use pmd mode netdev in OVS (huge performance improve)
> > - remove malloc dp_packet, instead put dp_packet in umem
> >
> > v2->v3:
> > - rebase on the OVS master, 7ab4b0653784
> > ("configure: Check for more specific function to pull in pthread
> > library.")
> > - remove the dependency on libbpf and dpif-bpf.
> > instead, use the built-in XDP_ATTACH feature.
> > - data structure optimizations for better performance, see[1]
> > - more test cases support
> > v3:
> > https://mail.openvswitch.org/pipermail/ovs-dev/2018-November/354179.html
> >
> > v3->v4:
> > - Use AF_XDP API provided by libbpf
> > - Remove the dependency on XDP_ATTACH kernel patch set
> > - Add documentation, bpf.rst
> >
> > v4->v5:
> > - rebase to master
> > - remove rfc, squash all into a single patch
> > - add --enable-afxdp, so by default, AF_XDP is not compiled
> > - add options: xdpmode=drv,skb
> > - add multiple queue and multiple PMD support, with options: n_rxq
> > - improve documentation, rename bpf.rst to af_xdp.rst
> >
> > v5->v6
> > - rebase to master, commit 0cdd5b13de91b98
> > - address errors from sparse and clang
> > - pass travis-ci test
> > - address feedback from Ben
> > - fix issues reported by 0-day robot
> > - improved documentation
> >
> > v6-v7
> > - rebase to master, commit abf11558c1515bf3b1
> > - address feedbacks from Ilya, Ben, and Eelco, see:
> > https://www.mail-archive.com/ovs-dev@openvswitch.org/msg32357.html
> > - add XDP mode change, implement get/set_config, reconfigure
> > - Fix reconfiguration/crash issue caused by libbpf, see patch:
> > [PATCH bpf 0/2] libbpf: fixes for AF_XDP teardown
> > - perf optimization for batching umem_push/pop
> > - perf optimization for batching kick_tx
> > - test build with dpdk
> > - fix/refactor atomic operation
> > - make AF_XDP x86 specific, otherwise fail at build time
> > - lots of code refactoring
> > - add PVP setup in documentation
> >
> > v7-v8:
> > - Address feedback from Ilya at:
> > https://patchwork.ozlabs.org/patch/1095019/
> > - add netdev-linux-private.h
> > - fix afxdp reconfigure issue
> > - sort include headers
> > - remove
Re: [ovs-dev] [PATCH v10] Improved Packet Drop Statistics in OVS
On 6/6/2019 10:27 PM, Anju Thomas wrote:
Currently OVS maintains explicit packet drop/error counters only on port level.
Packets that are dropped as part of normal OpenFlow processing are counted in
flow stats of “drop” flows or as table misses in table stats.
These can only be interpreted by controllers that know the semantics of the
configured OpenFlow pipeline. Without that knowledge, it is impossible for an
OVS user to obtain e.g. the total number of packets dropped due to OpenFlow
rules.
Furthermore, there are numerous other reasons for which packets can be dropped
by OVS slow path that are not related to the OpenFlow pipeline.
The generated datapath flow entries include a drop action to avoid further
expensive upcalls to the slow path, but subsequent packets dropped by the
datapath are not accounted anywhere.
Finally, the datapath itself drops packets in certain error situations.
Also, these drops are today not accounted for.
This makes it difficult for OVS users to monitor packet drop in an OVS instance
and to alert a management system in case of a unexpected increase of such
drops. Also OVS trouble-shooters face difficulties in analysing packet drops.
With this patch we implement following changes to address the issues mentioned
above.
1. Identify and account all the silent packet drop scenarios
2. Display these drops in ovs-appctl coverage/show
A detailed presentation on this was presented at OvS conference 2017 and link
for the corresponding presentation is available at:
https://www.slideshare.net/LF_OpenvSwitch/lfovs17troubleshooting-the-data-plane-in-ovs-82280329
Co-authored-by: Rohith Basavaraja
Co-authored-by: Keshav Gupta
Signed-off-by: Anju Thomas
Signed-off-by: Rohith Basavaraja
Signed-off-by: Keshav Gupta
Hi Anju et al,
I am going to review and test this patch, however, I do have a request
just below...
---
Here, below the three dash line just above, there should be an
accounting of all changes from version 1 of
this patch set to version 10. Something like this:
v9 -> v10 Changed something due to review comments etc...
v8 -> v9 Describe changes from v8 to v9 etc...
I think it's essential to reviewers to understand the previous patches
and their evolution to the current patch.
Thanks,
- Greg
datapath/linux/compat/include/linux/openvswitch.h | 1 +
lib/dpif-netdev.c | 46 -
lib/dpif.c| 7 +
lib/dpif.h| 4 +
lib/odp-execute.c | 78
lib/odp-util.c| 9 +
ofproto/ofproto-dpif-ipfix.c | 1 +
ofproto/ofproto-dpif-sflow.c | 1 +
ofproto/ofproto-dpif-xlate.c | 34 +++-
ofproto/ofproto-dpif-xlate.h | 3 +
ofproto/ofproto-dpif.c| 7 +
ofproto/ofproto-dpif.h| 8 +-
tests/automake.mk | 3 +-
tests/dpif-netdev.at | 8 +
tests/drop-stats.at | 211 ++
tests/ofproto-dpif.at | 2 +-
tests/tunnel-push-pop.at | 29 ++-
tests/tunnel.at | 14 +-
18 files changed, 455 insertions(+), 11 deletions(-)
create mode 100644 tests/drop-stats.at
diff --git a/datapath/linux/compat/include/linux/openvswitch.h
b/datapath/linux/compat/include/linux/openvswitch.h
index 65a003a..2de702e 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -985,6 +985,7 @@ enum ovs_action_attr {
OVS_ACTION_ATTR_METER,/* u32 meter number. */
OVS_ACTION_ATTR_CLONE,/* Nested OVS_CLONE_ATTR_*. */
OVS_ACTION_ATTR_CHECK_PKT_LEN, /* Nested OVS_CHECK_PKT_LEN_ATTR_*. */
+OVS_ACTION_ATTR_DROP,
#ifndef __KERNEL__
OVS_ACTION_ATTR_TUNNEL_PUSH, /* struct ovs_action_push_tnl*/
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 5a6f2ab..ec72403 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -101,6 +101,17 @@ enum { MAX_METERS = 65536 };/* Maximum number of
meters. */
enum { MAX_BANDS = 8 }; /* Maximum number of bands / meter. */
enum { N_METER_LOCKS = 64 };/* Maximum number of meters. */
+COVERAGE_DEFINE(datapath_drop_meter);
+COVERAGE_DEFINE(datapath_drop_upcall_error);
+COVERAGE_DEFINE(datapath_drop_lock_error);
+COVERAGE_DEFINE(datapath_drop_userspace_action_error);
+COVERAGE_DEFINE(datapath_drop_tunnel_push_error);
+COVERAGE_DEFINE(datapath_drop_tunnel_pop_error);
+COVERAGE_DEFINE(datapath_drop_recirc_error);
+COVERAGE_DEFINE(datapath_drop_invalid_port);
+COVERAGE_DEFINE(datapath_drop_invalid_tnl_port);
+COVERAGE_DEFINE(datapath_drop_rx_invalid_packet);
+
/*
Re: [ovs-dev] [PATCH v2] ovn-controller: Fix chassis ovn-sbdb record init
On Wed, May 22, 2019 at 01:26:03PM +0200, Dumitru Ceara wrote: > The chassis_run code didn't take into account the scenario when the > system-id was changed in the Open_vSwitch table. Due to this the code > was trying to insert a new Chassis record in the OVN_Southbound DB with > the same Encaps as the previous Chassis record. The transaction used > to insert the new records was aborting due to the ["type", "ip"] > index constraint violation as we were creating new Encap entries with > the same "type" and "ip" as the old ones. > > In order to fix this issue the flow is now: > 1. the first time ovn-controller initializes the Chassis entry (shortly > after start up) we first check if there is a stale Chassis record in the > OVN_Southbound DB by checking if any of the old Encap entries associated > to the Chassis record match the new tunnel configuration. If found it > means that ovn-controller didn't shutdown gracefully last time it was > run so it didn't cleanup the Chassis table. Potentially in the meantime > the OVS system-id was also changed. We then update the stale entry with > the new configuration and store the last configured chassis-id in memory > to avoid walking the Chassis table every time. > 2. for subsequent chassis_run calls we use the last configured > chassis-id stored at the previous step to lookup the old Chassis record. > 3. when ovn-controller shuts down gracefully we lookup the Chassis > record based on the chassis-id stored in memory at steps 1 and 2 above. > This is to avoid failing to cleanup the Chassis record in OVN_Southbound > DB if the OVS system-id changes between the last call to chassis_run and > chassis_cleanup. > > With this commit we also: > - refactor chassis.c to abstract the string processing and use > library data structures (e.g., sset) > - rename the get_chassis_id function in ovn-controller.c to > get_ovs_chassis_id to avoid confusion with the newly added > chassis_get_id function from chassis.c which returns the last > successfully configured chassis-id. > - add a test case in ovn-controller.at to check that OVS system-id > changes are properly propagated to OVN_Southbound DB Thanks for working on this. This is a large patch that incorporates both a bug fix and refactoring. I would prefer to see the refactoring broken out into a separate patch. Preferably, it would go after the bug fix so that the bug fix could be backported by itself (if necessary), but if the refactoring is essential to the bug fix then the refactoring could go first. Would you mind breaking the patch apart? Thanks, Ben. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3] ovn: Add a new logical switch port type - 'virtual'
On Mon, May 27, 2019 at 12:52:24PM +0530, nusid...@redhat.com wrote:
> If suppose the virtual_ip is configured to 10.0.0.10 on a virtual logical
> port 'sw0-vip'
> and the virtual_parents are set to - [sw0-p1, sw0-p2] then below logical
> flows are added in the
> lsp_in_arp_rsp logical switch pipeline
>
> - table=11(ls_in_arp_rsp), priority=100,
>match=(inport == "sw0-p1" && ((arp.op == 1 && arp.spa == 10.0.0.10 &&
> arp.tpa == 10.0.0.10) ||
> (arp.op == 2 && arp.spa == 10.0.0.10))),
>action=(bind_vport("sw0-vip", inport); next;)
> - table=11(ls_in_arp_rsp), priority=100,
>match=(inport == "sw0-p2" && ((arp.op == 1 && arp.spa == 10.0.0.10 &&
> arp.tpa == 10.0.0.10) ||
> (arp.op == 2 && arp.spa == 10.0.0.10))),
>action=(bind_vport("sw0-vip", inport); next;)
>
> The action bind_vport will claim the logical port - sw0-vip on the chassis
> where this action
> is executed. Since the port - sw0-vip is claimed by a chassis, the
> dnat_and_snat rule for
> the VIP will be handled by the compute node.
The behavior here is a little bit different from what I ordinarily
expect in OVN. Usually, the flow table that ovn-northd outputs depends
only on the logical network topology and configuration. With this
change, the flow table also depends on state, and ovn-northd needs to
update it if that state changes.
A design that I would perceive as more in the spirit of the current
design would be one that always puts bind_vport on all of the chassis.
That would require some work in ovn-controller so that it doesn't
process a continuous stream of packets in the common case, but it would
fit the current design better.
Let me know if I misunderstand.
Thanks,
Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofproto-dpif-xlate: Report DHCP output actions in trace.
Bleep bloop. Greetings Ben Pfaff, 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. checkpatch: WARNING: Line is 88 characters long (recommended limit is 79) #17 FILE: ofproto/ofproto-dpif-xlate.c:1: /* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2019 Nicira, Inc. Lines checked: 32, Warnings: 1, Errors: 0 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
Re: [ovs-dev] [PATCH] OVN: grab pinctrl_mutex before running pinctrl_handle_buffered_packets
On Wed, May 15, 2019 at 12:16:42PM -0700, Han Zhou wrote:
> On Wed, May 15, 2019 at 6:34 AM Lorenzo Bianconi <
> lorenzo.bianc...@redhat.com> wrote:
> >
> > pinctrl_handle_buffered_packets can insert new elements in
> > buffered_packets_map hasmap and it runs concurrently with pinctrl_run
> > starting from commit 3594ffab6b4b. Fix possible races grabbing
> > pinctrl_mutex before running pinctrl_handle_buffered_packets
> >
> > Fixes: 3594ffab6b4b ("ovn-controller: Add a new thread in pinctrl module
> to handle packet-ins.")
> > Signed-off-by: Lorenzo Bianconi
> > ---
> > ovn/controller/pinctrl.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
> > index 8ae1f9bd6..c10693301 100644
> > --- a/ovn/controller/pinctrl.c
> > +++ b/ovn/controller/pinctrl.c
> > @@ -464,6 +464,7 @@ static int
> > pinctrl_handle_buffered_packets(const struct flow *ip_flow,
> > struct dp_packet *pkt_in,
> > const struct match *md, bool is_arp)
> > +OVS_REQUIRES(pinctrl_mutex)
> > {
> > struct buffered_packets *bp;
> > struct dp_packet *clone;
> > @@ -512,7 +513,9 @@ pinctrl_handle_arp(struct rconn *swconn, const struct
> flow *ip_flow,
> > return;
> > }
> >
> > +ovs_mutex_lock(_mutex);
> > pinctrl_handle_buffered_packets(ip_flow, pkt_in, md, true);
> > +ovs_mutex_unlock(_mutex);
> >
> > /* Compose an ARP packet. */
> > uint64_t packet_stub[128 / 8];
> > @@ -3136,7 +3139,9 @@ pinctrl_handle_nd_ns(struct rconn *swconn, const
> struct flow *ip_flow,
> > return;
> > }
> >
> > +ovs_mutex_lock(_mutex);
> > pinctrl_handle_buffered_packets(ip_flow, pkt_in, md, false);
> > +ovs_mutex_unlock(_mutex);
> >
> > uint64_t packet_stub[128 / 8];
> > struct dp_packet packet;
> > --
> > 2.20.1
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
> Thanks for the fix!
>
> Acked-by: Han Zhou
Thanks Lorenzo (and Han). I applied this to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] OVN: do not distribute traffic for local FIP
On Mon, May 27, 2019 at 11:00:17AM +0200, Lorenzo Bianconi wrote: > Do not send traffic for local FIP through the overlay tunnels but > manage it in the local hypervisor > > Signed-off-by: Lorenzo Bianconi This is one where I'd appreciate a review by someone else knowledgeable of the context. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3] datapath: Fix build errors for 4.9.172+ kernels
On Fri, May 24, 2019 at 01:32:42PM -0700, Yi-Hung Wei wrote:
> On Fri, May 24, 2019 at 11:24 AM Yifeng Sun wrote:
> >
> > 4.9.172+ kernel backported upstream patch 70b095c843266
> > ("ipv6: remove dependency of nf_defrag_ipv6 on ipv6 module")
> > and this caused compilation errors of OVS kernel module.
> >
> > This patch fixes it by checking and using new functions
> > introduced by the upstream patch.
> >
> > Travis tests passed at
> > https://travis-ci.org/yifsun/ovs-travis/builds/536527230
> > with latest Linux kernel version.
> >
> > In addition, this patch doesn't introduce failed tests for latest kernels
> > of Ubuntu (bionic, trusty, xenial), fedora, centos 73, rhel (74, 75, 76).
> >
> > Reported-by: Ilya Maximets
> > Signed-off-by: Yifeng Sun
> > ---
> Thanks for the update. It looks good to me.
>
> Acked-by: Yi-Hung Wei
Yifeng and Yi-Hung, thank you.
I applied this patch to master. Let me know if it should be backported.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] ofproto-dpif-xlate: Report DHCP output actions in trace.
Signed-off-by: Ben Pfaff --- ofproto/ofproto-dpif-xlate.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c index 04d69ed06c20..ea72eedb1cde 100644 --- a/ofproto/ofproto-dpif-xlate.c +++ b/ofproto/ofproto-dpif-xlate.c @@ -1,4 +1,4 @@ -/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017 Nicira, Inc. +/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2019 Nicira, Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. @@ -7588,6 +7588,8 @@ xlate_actions(struct xlate_in *xin, struct xlate_out *xout) WC_MASK_FIELD(ctx.wc, tp_src); WC_MASK_FIELD(ctx.wc, tp_dst); WC_MASK_FIELD(ctx.wc, dl_type); +xlate_report(, OFT_DETAIL, "outputting DHCP packet " + "to local port for in-band control"); compose_output_action(, OFPP_LOCAL, NULL, false, false); } -- 2.20.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1] Incorrect match criteria for in-band control rule
On Wed, May 29, 2019 at 09:54:04AM +, Anju Thomas wrote: > As part of in-band control, OVS is expected to send DHCP server replies to > the LOCAL port as well. In this case, OVS implicitly adds an additional > action to output to the bridge’s LOCAL port after the ofproto translation for > the packet is completed in the ofproto layer but before sending the actions > to datapath for installation. > However, the match criteria is unchanged and as a result all packets (not > just DHCP server replies) are also sent to the LOCAL port. > The fix is to add the IP protocol type (UDP), the UDP source and destination > ports to the match criteria so that a specific datapath flow that matches > only DHCP server replies is installed. As a result, only DHCP server reply > packets will be sent to the LOCAL port. > > Signed-off-by: Anju Thomas Thank you! I applied this to master. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofproto-dpif-xlate: Do not use zero-weight buckets in select groups.
Bleep bloop. Greetings Ben Pfaff, 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. checkpatch: WARNING: Line is 88 characters long (recommended limit is 79) #23 FILE: ofproto/ofproto-dpif-xlate.c:1: /* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2019 Nicira, Inc. Lines checked: 47, Warnings: 1, Errors: 0 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
Re: [ovs-dev] [patch v5] conntrack: ignore port for ICMP/ICMPv6 NAT.
On Wed, Jun 05, 2019 at 03:35:34PM -0700, Darrell Ball wrote:
> From: solomon
>
> ICMP/ICMPv6 fails, if the src/dst port is set in a common NAT rule.
> For example:
> actions=ct(nat(dst=172.16.1.100:5000),commit,table=40)
>
> Fixes: 4cd0481c9e8b ("conntrack: Fix wasted work for ICMP NAT.")
> CC: Darrell Ball
> Signed-off-by: solomon
> Signed-off-by: Darrell Ball
> Co-authored-by: Darrell Ball
Thanks, solomon and Darrell. I applied this to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] lib/flow.c: Don't include ports of first fragments in hash
On Wed, Jun 05, 2019 at 10:36:33PM +, Van Bemmel, Jeroen (Nokia - US) wrote: > For a series of IP fragments, only the first packet includes the transport > header (TCP/UDP/SCTP) and the src/dst ports. By including these port > numbers in the hash, it may happen that a first fragment hashes to a > different value than subsequent packets, causing different packets from > the same flow to follow different paths. This in turn may result in > out-of-order delivery or failed reassembly. This patch excludes port > numbers from the hash calculation in case of IP fragmentation. > > Signed-off-by: Jeroen van Bemmel I applied this to master, thanks! ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] why the behavior for weigh=0 for group's dp_hash method is different with default selection method?
On Wed, May 29, 2019 at 08:05:13PM +0800, ychen wrote:
> hi,
>I noticed that we can set bucket's weight to 0 when add/mod group.
>1. when we use default select method, and when all the buckets with weight
> larger than 0 change to dead,
> we can still pick the bucket whose weight is 0. here is the code:
> pick_default_select_group()->group_best_live_bucket():
> LIST_FOR_EACH (bucket, list_node, >up.buckets) {
> if (bucket_is_alive(ctx, bucket, 0)) { / so when only
> bucket with weight=0 is active
> uint32_t score =
> (hash_int(bucket->bucket_id, basis) & 0x) *
> bucket->weight;
> if (score >= best_score) { and bucket with
> weight=0 does match this clause
> best_bucket = bucket;
> best_score = score;
> }
>
>
> 2. but for dp_hash selection method, we init the bucket when group_construct
> and bucket whose weight is 0 will be excluded. Here is the code:
> for (int hash = 0; hash < n_hash; hash++) {
> struct webster *winner = [0];
> for (i = 1; i < n_buckets; i++) {
> if (webster[i].value > winner->value) { bucket with
> weight=0 always be excluded
> winner = [i];
> }
> }
>
>
> so here is my question: why the behavior is different for dp_hash method and
> default selection method?
Thank you for the bug report.
I sent a fix for review:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-June/359559.html
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] ofproto-dpif-xlate: Do not use zero-weight buckets in select groups.
The OpenFlow specification says that buckets in select groups with a weight
of zero should not be selected, but the ofproto-dpif implementation could
select them in corner cases. This fixes the problem.
Reported-by: ychen
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2019-May/359349.html
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-xlate.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index ae8b9991c7cd..da7fa56362d3 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017 Nicira,
Inc.
+/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2019
Nicira, Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -1929,7 +1929,7 @@ group_best_live_bucket(const struct xlate_ctx *ctx,
struct ofputil_bucket *bucket;
LIST_FOR_EACH (bucket, list_node, >up.buckets) {
-if (bucket_is_alive(ctx, bucket, 0)) {
+if (bucket_is_alive(ctx, bucket, 0) && bucket->weight > 0) {
uint32_t score =
(hash_int(bucket->bucket_id, basis) & 0x) * bucket->weight;
if (score >= best_score) {
@@ -4535,7 +4535,7 @@ pick_dp_hash_select_group(struct xlate_ctx *ctx, struct
group_dpif *group)
for (int i = 0; i <= hash_mask; i++) {
struct ofputil_bucket *b =
group->hash_map[(dp_hash + i) & hash_mask];
-if (bucket_is_alive(ctx, b, 0)) {
+if (bucket_is_alive(ctx, b, 0) && b->weight > 0) {
return b;
}
}
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Estrategia logística
¡Hola! Me da mucho gusto saludarte. Es para mi un placer poder invitarte a nuestro webinar "Estrategia logística: Aprovisionamiento y distribución" que se estará llevando a cabo el día jueves 27 de junio con un horario de 10:00 a 17:00 hrs. (hora de la ciudad de México) Con este curso en línea lograremos: - Conocer el alcance e impacto operacional, financiero y comercial de la logística de materiales, en el contexto integral de la organización productiva y/o comercializadora. - Aprender elementos para la gestión de actividades de apoyo a la logística de materiales, tales como el almacenamiento y el transporte. -Aprender técnicas y herramientas de la gestión logística para la producción de métricas de desempeño. El experto que nos acompañará será Alejandro Ibarra, quién cuenta con más de 30 años de experiencia profesional a nivel directivo en las funciones de compras, logística y comercio exterior en empresas multinacionales, privadas y públicas. Ha tenido responsabilidad directa en planeación estratégica de suministros, negociación y creación de contratos, logro de ahorros, planeación de la producción y gestión de almacenes, inventarios y distribución. También es negociador experimentado con proveedores internacionales, liderando equipos de compras y participante de equipos negociadores corporativos. Tiene una amplia capacidad de manejo de entornos multinacionales y multiculturales. Te invito a que participes con nosotros y conozcas los beneficios de la capacitación en línea. Tel: (045) 55 15 54 66 30 Solicita información respondiendo a este correo con la palabra Logística, junto con los siguientes datos: Nombre: Correo electrónico: Número telefónico: ¡Qué tengas un excelente día! ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] datapath flow will match packet's tll when we use dec_ttl in action
On Wed, May 29, 2019 at 08:26:12PM +0800, ychen wrote: > hi, >when I send IP packets with ttl in IP header is random in range(1-255), > and with all other IP header fields stay not changed > but generated 255 datapath flows each with different ttl value. > of course, i use the action dec_ttl, here is code: > case OFPACT_DEC_TTL: > wc->masks.nw_ttl = 0xff; > > >my question is: can we optimize the dec_ttl action? only differentiate > TTL>1 and TTL <=1? >as we all know, when TTL=0, we should send packet to the controller, and > let it make decision whether we should send icmp error packet out. >when TTL is larger than 1, I think they are no difference, am i right? This optimization is not too valuable, because in practice IP packets don't have random TTLs. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 2/2] Don't send or receive LACP PDUs when carrier state of slave is down
On Thu, Jun 06, 2019 at 06:34:21AM +, Nitin Katiyar wrote: > > > > -Original Message- > > From: Ben Pfaff [mailto:b...@ovn.org] > > Sent: Wednesday, June 05, 2019 12:03 AM > > To: Nitin Katiyar > > Cc: ovs-dev@openvswitch.org; Manohar Krishnappa Chidambaraswamy > > > > Subject: Re: [ovs-dev] [PATCH v2 2/2] Don't send or receive LACP PDUs when > > carrier state of slave is down > > > > On Sun, Jun 02, 2019 at 04:14:34PM +, Nitin Katiyar wrote: > > > Problem: > > > > > > On certain Fortville NICs it has been observed that PHY UP detection > > > can get delayed (sometimes up to 4-5 secs). When the driver fails to > > > fetch PHY status as UP even though its actually UP, LACP packets can > > > get exchanged and LACP slave brought UP. In such a case, the remote > > > end would start sending traffic on that slave, but OVS drops it, as > > > the bond-slave is not yet enabled due to PHY DOWN. > > > > > > Fix: > > > > > > The main intention here is delay LACP negotiation until carrier (PHY) > > > status is read as UP. > > > > > > 1. When carrier state is DOWN, do not send any LACP PDUs and > > > drop any received LACP PDUs. > > > > > > 2. When LACP PDU is received, trigger re-checking > > > of carrier-state (in port_run()) by incrementing the connectivity > > > sequence number to find out the true carrier state as fast as > > > possible. > > > > I had to read this patch and the above description a few times. Maybe I > > understand it now. Please let me try to re-state it and let me know if > > I've got it > > right. > > > > Fortville NICs (or perhaps their drivers) do not consistently send an > > immediate > > notification when the PHY comes up. However, packets can still be received. > > Until now, OVS drops traffic until the notification that the PHY is up > > arrives. > > This patch changes OVS to respond to receiving a LACP packet on a device, > > for > > which it has not yet been notified that carrier is up, by immediately > > polling > > carrier state. This polling can bypass the Fortville delayed notification > > and > > allow OVS to bring up the bond slave faster. > It is other way. Until now, OVS (and connected switch) may see LACP in > negotiated state but OVS may have link/carrier state as DOWN due to > NIC/driver issue. > In this case, NIC/driver didn't update the link UP state for few seconds > although link had come up and started carrying traffic. This brought up the > LACP slave and remote end started traffic on this slave. OVS dropped the > packets as slave status was down. > To avoid this situation we propose this patch for not sending/receiving LACP > PDUs till link is reported UP. In short, we delay LACP negotiation till > carrier status is UP. Additionally, if PMD is receiving LACP PDU when carrier > state is down it triggers checking of state by changing connectivity sequence > number. OK, let me try again. Is the following correct? --8<--cut here-->8-- Fortville NICs (or their drivers) can get into an inconsistent state, in which the NIC can actually transmit and receive packets even though they report "PHY down". In such a state, OVS can exchange and process LACP messages and enable a bond slave. However, further packet exchange over the slave fails because OVS sees that the PHY is down. This commit fixes the problem by making OVS ignore received LACP PDUs and suppress transmitting LACP PDUs when carrier is down. In addition, when a LACP PDU is received with carrier down, this commit triggers rechecking the carrier status (by incrementing the connectivity sequence number) to ensure that it is updated as quickly as possible. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] Add support for DHCP option 15 - domain name
On Fri, Jun 07, 2019 at 02:14:28PM +0200, mjoze...@redhat.com wrote: > From: Maciej Józefczyk > > For Openstack Internal DNS functionality we need > to provide support for domain_name option. > DHCP option 15 was previously used only in parser > tests and according to RFC it should be renamed to > domain_name [1]. > > This patch modifies its name in the tests from > 'domain' to 'domain_name' and adds its support > to the code. > > [1] https://tools.ietf.org/html/rfc2132#section-3.17 > > Signed-off-by: Maciej Józefczyk Applied to master, thanks! ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3] ovn-controller: Fix parsing of OVN tunnel IDs
On Mon, May 27, 2019 at 10:55:52AM +0200, Dumitru Ceara wrote:
> Encap tunnel-ids are of the form:
> .
> In physical_run we were checking if a tunnel-id corresponds
> to the local chassis-id by searching if the chassis-id string
> is included in the tunnel-id (strstr). This can break quite
> easily, for example, if the local chassis-id is a substring
> of a remote chassis-id. In that case we were wrongfully
> skipping the tunnel creation.
>
> To fix that new tunnel-id creation and parsing functions are added in
> encaps.[ch]. These functions are now used everywhere where applicable.
>
> Acked-by: Venu Iyer
> Reported-at: https://bugzilla.redhat.com/1708131
> Reported-by: Haidong Li
> Fixes: b520ca7 ("Support for multiple VTEP in OVN")
> Signed-off-by: Dumitru Ceara
> ---
>
> v3: Rebase
> v2: Update commit message
This seems about right.
Here's an incremental with some suggestions for encaps_tunnel_id_parse()
and encaps_tunnel_id_match(). I'm pretty happy with the
encaps_tunnel_id_parse() change; the encaps_tunnel_id_match() one might
be going over the top.
Let me know what you think.
diff --git a/ovn/controller/encaps.c b/ovn/controller/encaps.c
index 61b3eab3971f..3b3921a736e2 100644
--- a/ovn/controller/encaps.c
+++ b/ovn/controller/encaps.c
@@ -102,64 +102,51 @@ encaps_tunnel_id_create(const char *chassis_id, const
char *encap_ip)
* If the 'encap_ip' argument is not NULL the function will allocate memory
* and store the encapsulation IP part of the tunnel-id at '*encap_ip'.
*/
-bool encaps_tunnel_id_parse(const char *tunnel_id, char **chassis_id,
-char **encap_ip)
+bool
+encaps_tunnel_id_parse(const char *tunnel_id, char **chassis_id,
+ char **encap_ip)
{
-const char *match = strchr(tunnel_id, OVN_MVTEP_CHASSISID_DELIM);
-
-if (!match) {
+/* Find the delimiter. Fail if there is no delimiter or if
+ * or is the empty string.*/
+const char *d = strchr(tunnel_id, OVN_MVTEP_CHASSISID_DELIM);
+if (d == tunnel_id || !d || !d[1]) {
return false;
}
if (chassis_id) {
-size_t chassis_id_len = (match - tunnel_id);
-
-*chassis_id = xmemdup0(tunnel_id, chassis_id_len);
+*chassis_id = xmemdup0(tunnel_id, d - tunnel_id);
}
-
-/* Consume the tunnel-id delimiter. */
-match++;
-
if (encap_ip) {
-/*
- * If the value has morphed into something other than
- * , fail and free already allocated
- * memory (i.e., chassis_id).
- */
-if (*match == 0) {
-if (chassis_id) {
-free(*chassis_id);
-}
-return false;
-}
-*encap_ip = xstrdup(match);
+*encap_ip = xstrdup(d + 1);
}
-
return true;
}
/*
- * Returns true if a given tunnel_id contains 'chassis_id' and, if specified,
- * the given 'encap_ip'. Returns false otherwise.
+ * Returns true if 'tunnel_id' contains 'chassis_id' and, if specified, the
+ * given 'encap_ip'. Returns false otherwise.
*/
-bool encaps_tunnel_id_match(const char *tunnel_id, const char *chassis_id,
-const char *encap_ip)
+bool
+encaps_tunnel_id_match(const char *tunnel_id, const char *chassis_id,
+ const char *encap_ip)
{
-if (strstr(tunnel_id, chassis_id) != tunnel_id) {
-return false;
-}
-
-size_t chassis_id_len = strlen(chassis_id);
-
-if (tunnel_id[chassis_id_len] != OVN_MVTEP_CHASSISID_DELIM) {
-return false;
-}
-
-if (encap_ip && strcmp(_id[chassis_id_len + 1], encap_ip)) {
-return false;
+while (*tunnel_id == *chassis_id) {
+if (!*tunnel_id) {
+/* 'tunnel_id' and 'chassis_id' are equal strings. This is a
+ * mismatch because 'tunnel_id' is missing the delimiter and IP. */
+return false;
+}
+tunnel_id++;
+chassis_id++;
}
-return true;
+/* We found the first byte that disagrees between 'tunnel_id' and
+ * 'chassis_id'. If we consumed all of 'chassis_id' and arrived at the
+ * delimiter in 'tunnel_id' (and if 'encap_ip' is correct, if it was
+ * supplied), it's a match. */
+return (*tunnel_id == OVN_MVTEP_CHASSISID_DELIM
+&& *chassis_id == '\0'
+&& (!encap_ip || !strcmp(tunnel_id + 1, encap_ip)));
}
static void
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 1/4] ip6_gre: Fix a bug that clears address bits
Done. On Thu, Jun 06, 2019 at 05:55:33PM -0700, Yifeng Sun wrote: > Hi Ben, > > Can you please backport this patch to 2.10, thanks. > > Yifeng > > On Thu, Aug 16, 2018 at 9:14 AM Gregory Rose wrote: > > > > > > On 8/15/2018 6:24 AM, Yifeng Sun wrote: > > > In compatable gre module, skb->cb is solely used as ovs_gso_cb. > > > However, IPCB(skb) also points to skb->cb. IPCB(skb)->flags overlaps > > > with ovs_gso_cb.tun_dst. As a result, this bug clears the 16-23 bit > > > in the address of ovs_gso_cb.tun_dst and causes kernel to crash. > > > > > > Signed-off-by: Yifeng Sun > > > --- > > > v1->v2: Improved commit message and fixed __gre6_xmit, thanks Greg! > > > > > > datapath/linux/compat/ip6_gre.c | 4 > > > 1 file changed, 4 deletions(-) > > > > > > diff --git a/datapath/linux/compat/ip6_gre.c > > > b/datapath/linux/compat/ip6_gre.c > > > index 54a76ab..3904455 100644 > > > --- a/datapath/linux/compat/ip6_gre.c > > > +++ b/datapath/linux/compat/ip6_gre.c > > > @@ -876,9 +876,6 @@ static netdev_tx_t __gre6_xmit(struct sk_buff *skb, > > > struct tnl_ptk_info tpi; > > > __be16 protocol; > > > > > > - if (dev->type == ARPHRD_ETHER) > > > - IPCB(skb)->flags = 0; > > > - > > > if (dev->header_ops && dev->type == ARPHRD_IP6GRE) > > > fl6->daddr = ((struct ipv6hdr *)skb->data)->daddr; > > > else > > > @@ -1146,7 +1143,6 @@ static netdev_tx_t ip6erspan_tunnel_xmit(struct > > > sk_buff *skb, > > > goto tx_err; > > > > > > t->parms.o_flags &= ~TUNNEL_KEY; > > > - IPCB(skb)->flags = 0; > > > > > > tun_info = ovs_skb_tunnel_info(skb); > > > if (unlikely(!tun_info || > > > > Looks good. > > > > Tested-by: Greg Rose > > Reviewed-by: Greg Rose > > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCHv11] netdev-afxdp: add new netdev type for AF_XDP.
Hi William,
No review or full test yet, just some observations…
We run OVS as a non root user, which is causing OVS with XDP to fail:
2019-06-07T09:14:20.628Z|00023|ofproto_dpif|INFO|netdev@ovs-netdev:
Datapath supports ct_orig_tuple
2019-06-07T09:14:20.628Z|00024|ofproto_dpif|INFO|netdev@ovs-netdev:
Datapath supports ct_orig_tuple6
2019-06-07T09:14:20.664Z|00025|dpif_netdev|INFO|PMD thread on numa_id:
0, core id: 21 created.
2019-06-07T09:14:20.664Z|00026|dpif_netdev|INFO|There are 1 pmd threads
on numa node 0
2019-06-07T09:14:20.664Z|00027|netdev_afxdp|INFO|remove xdp program
2019-06-07T09:14:20.664Z|00028|netdev_afxdp|INFO|AF_XDP device eno1 in
DRV mode
2019-06-07T09:14:20.664Z|00029|netdev_afxdp|ERR|ERROR:
setrlimit(RLIMIT_MEMLOCK): Operation not permitted
2019-06-07T09:14:20.664Z|00030|netdev_afxdp|INFO|xsk_configure_all
configure queue 0 mode DRV
2019-06-07T09:14:20.672Z|00031|netdev_afxdp|ERR|xsk_socket__create
failed (Operation not permitted) mode: DRV qid: 0
2019-06-07T09:14:20.686Z|00032|netdev_afxdp|ERR|failed to create AF_XDP
socket on queue 0
2019-06-07T09:14:20.686Z|00033|netdev_afxdp|INFO|remove xdp program
2019-06-07T09:14:20.687Z|00034|netdev_afxdp|ERR|AF_XDP device eno1
reconfig fails
2019-06-07T09:14:20.687Z|00035|dpif_netdev|ERR|Failed to set interface
eno1 new configuration
However when configuring this after startup it’s fine, but trying to
restart OVS with this configuration results in a system core…
On 5 Jun 2019, at 22:47, William Tu wrote:
The patch introduces experimental AF_XDP support for OVS netdev.
AF_XDP, the Address Family of the eXpress Data Path, is a new Linux
socket
type built upon the eBPF and XDP technology. It is aims to have
comparable
performance to DPDK but cooperate better with existing kernel's
networking
stack. An AF_XDP socket receives and sends packets from an eBPF/XDP
program
attached to the netdev, by-passing a couple of Linux kernel's
subsystems
As a result, AF_XDP socket shows much better performance than
AF_PACKET
For more details about AF_XDP, please see linux kernel's
Documentation/networking/af_xdp.rst. Note that by default, this
feature is
not compiled in.
Signed-off-by: William Tu
---
v1->v2:
- add a list to maintain unused umem elements
- remove copy from rx umem to ovs internal buffer
- use hugetlb to reduce misses (not much difference)
- use pmd mode netdev in OVS (huge performance improve)
- remove malloc dp_packet, instead put dp_packet in umem
v2->v3:
- rebase on the OVS master, 7ab4b0653784
("configure: Check for more specific function to pull in pthread
library.")
- remove the dependency on libbpf and dpif-bpf.
instead, use the built-in XDP_ATTACH feature.
- data structure optimizations for better performance, see[1]
- more test cases support
v3:
https://mail.openvswitch.org/pipermail/ovs-dev/2018-November/354179.html
v3->v4:
- Use AF_XDP API provided by libbpf
- Remove the dependency on XDP_ATTACH kernel patch set
- Add documentation, bpf.rst
v4->v5:
- rebase to master
- remove rfc, squash all into a single patch
- add --enable-afxdp, so by default, AF_XDP is not compiled
- add options: xdpmode=drv,skb
- add multiple queue and multiple PMD support, with options: n_rxq
- improve documentation, rename bpf.rst to af_xdp.rst
v5->v6
- rebase to master, commit 0cdd5b13de91b98
- address errors from sparse and clang
- pass travis-ci test
- address feedback from Ben
- fix issues reported by 0-day robot
- improved documentation
v6-v7
- rebase to master, commit abf11558c1515bf3b1
- address feedbacks from Ilya, Ben, and Eelco, see:
https://www.mail-archive.com/ovs-dev@openvswitch.org/msg32357.html
- add XDP mode change, implement get/set_config, reconfigure
- Fix reconfiguration/crash issue caused by libbpf, see patch:
[PATCH bpf 0/2] libbpf: fixes for AF_XDP teardown
- perf optimization for batching umem_push/pop
- perf optimization for batching kick_tx
- test build with dpdk
- fix/refactor atomic operation
- make AF_XDP x86 specific, otherwise fail at build time
- lots of code refactoring
- add PVP setup in documentation
v7-v8:
- Address feedback from Ilya at:
https://patchwork.ozlabs.org/patch/1095019/
- add netdev-linux-private.h
- fix afxdp reconfigure issue
- sort include headers
- remove unnecessary OVS_UNUSED
- coding style fixes
- error case handling and memory leak
v8-v9:
- rebase to master 180bbbed3a3867d52
- Address review feedback from Ben, Ilya and Eelco, at:
https://patchwork.ozlabs.org/patch/1097740/
- == From Ilya ==
- Optimize the reconfiguration logic
- Implement .rxq_recv and .send for afxdp
- Remove system-afxdp-traffic.at, reuse existing code
- Use Ilya's rdtsc code
- remove --disable-system
- == From Eelco ==
- Fix bug when remove br0,
util(revalidator49)|EMER|lib/poll-loop.c:111:
assertion !fd != !wevent failed
- Fix bug and use default value from libbpf, ex:
XSK_RING_PROD__DEFAULT...
- Clear xdp program when receive signal, ctrl+c
- Add options to
Re: [ovs-dev] [PATCH] Detailed packet drop statistics per dpdk and vhostuser ports
On 07.06.2019 17:28, Ilya Maximets wrote: > On 07.06.2019 15:39, Sriram Vatala wrote: >> OVS may be unable to transmit packets for multiple reasons and >> today there is a single counter to track packets dropped due to >> any of those reasons. The most common reason is that a VM is >> unable to read packets fast enough causing the vhostuser port >> transmit queue on the OVS side to become full. This manifests >> as a problem with VNFs not receiving all packets. Having a >> separate drop counter to track packets dropped because the >> transmit queue is full will clearly indicate that the problem >> is on the VM side and not in OVS. Similarly maintaining separate >> counters for all possible drops helps in indicating sensible >> cause for packet drops. >> >> This patch adds counters to track packets dropped due to all possible >> reasons and display them when "--details" optional flag is passed to >> “ovs-appctl dpctl/show -s” . The detailed stats will be available >> for both dpdk and vhostuser ports. >> >> cmd Usage : "ovs-appctl dpctl/show -s --details" (OR) >> "ovs-appctl dpctl/show --statistics --details" >> >> Following are the details of the new counters : >> >> queue_full : These are the packets dropped due to Transmit queue overrun. >> mtu_exceeded : These are the packets dropped due to MTU mismatch. >>(i.e Pkt len > Max Dev MTU) >> qos : These are the packets dropped due to transmission/reception rate >> exceeding the configured Egress/Ingress policer rate on the interface. >> >> Signed-off-by: Sriram Vatala >> --- >> include/openvswitch/netdev.h | 8 >> lib/dpctl.c | 26 ++- >> lib/dpctl.h | 5 + >> lib/dpctl.man| 8 ++-- >> lib/netdev-dpdk.c| 49 >> +--- >> 5 files changed, 86 insertions(+), 10 deletions(-) > > Hi, Sriram. > Thanks for working on OVS improvement. > > I didn't look at the code yet, but one thing I wanted to mention is that > dpctl interface seems redundant here. It provides only basic statistics, > but you're adding some really specific stuff. Also, full port stats are > always available via db interface: > > ovs-vsctl get interface statistics > > Your new stats counters will be there automatically. Only need to add a few lines to '#define IFACE_STATS' in vswitchd/bridge.c. > I think, it's better to drop dpctl parts of this patch. > > 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] Detailed packet drop statistics per dpdk and vhostuser ports
On 07.06.2019 15:39, Sriram Vatala wrote: > OVS may be unable to transmit packets for multiple reasons and > today there is a single counter to track packets dropped due to > any of those reasons. The most common reason is that a VM is > unable to read packets fast enough causing the vhostuser port > transmit queue on the OVS side to become full. This manifests > as a problem with VNFs not receiving all packets. Having a > separate drop counter to track packets dropped because the > transmit queue is full will clearly indicate that the problem > is on the VM side and not in OVS. Similarly maintaining separate > counters for all possible drops helps in indicating sensible > cause for packet drops. > > This patch adds counters to track packets dropped due to all possible > reasons and display them when "--details" optional flag is passed to > “ovs-appctl dpctl/show -s” . The detailed stats will be available > for both dpdk and vhostuser ports. > > cmd Usage : "ovs-appctl dpctl/show -s --details" (OR) > "ovs-appctl dpctl/show --statistics --details" > > Following are the details of the new counters : > > queue_full : These are the packets dropped due to Transmit queue overrun. > mtu_exceeded : These are the packets dropped due to MTU mismatch. >(i.e Pkt len > Max Dev MTU) > qos : These are the packets dropped due to transmission/reception rate > exceeding the configured Egress/Ingress policer rate on the interface. > > Signed-off-by: Sriram Vatala > --- > include/openvswitch/netdev.h | 8 > lib/dpctl.c | 26 ++- > lib/dpctl.h | 5 + > lib/dpctl.man| 8 ++-- > lib/netdev-dpdk.c| 49 > +--- > 5 files changed, 86 insertions(+), 10 deletions(-) Hi, Sriram. Thanks for working on OVS improvement. I didn't look at the code yet, but one thing I wanted to mention is that dpctl interface seems redundant here. It provides only basic statistics, but you're adding some really specific stuff. Also, full port stats are always available via db interface: ovs-vsctl get interface statistics Your new stats counters will be there automatically. I think, it's better to drop dpctl parts of this patch. What do you think? Best regards, Ilya Maximets. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] Detailed packet drop statistics per dpdk and vhostuser ports
OVS may be unable to transmit packets for multiple reasons and
today there is a single counter to track packets dropped due to
any of those reasons. The most common reason is that a VM is
unable to read packets fast enough causing the vhostuser port
transmit queue on the OVS side to become full. This manifests
as a problem with VNFs not receiving all packets. Having a
separate drop counter to track packets dropped because the
transmit queue is full will clearly indicate that the problem
is on the VM side and not in OVS. Similarly maintaining separate
counters for all possible drops helps in indicating sensible
cause for packet drops.
This patch adds counters to track packets dropped due to all possible
reasons and display them when "--details" optional flag is passed to
“ovs-appctl dpctl/show -s” . The detailed stats will be available
for both dpdk and vhostuser ports.
cmd Usage : "ovs-appctl dpctl/show -s --details" (OR)
"ovs-appctl dpctl/show --statistics --details"
Following are the details of the new counters :
queue_full : These are the packets dropped due to Transmit queue overrun.
mtu_exceeded : These are the packets dropped due to MTU mismatch.
(i.e Pkt len > Max Dev MTU)
qos : These are the packets dropped due to transmission/reception rate
exceeding the configured Egress/Ingress policer rate on the interface.
Signed-off-by: Sriram Vatala
---
include/openvswitch/netdev.h | 8
lib/dpctl.c | 26 ++-
lib/dpctl.h | 5 +
lib/dpctl.man| 8 ++--
lib/netdev-dpdk.c| 49 +---
5 files changed, 86 insertions(+), 10 deletions(-)
diff --git a/include/openvswitch/netdev.h b/include/openvswitch/netdev.h
index 0c10f7b..69480a4 100644
--- a/include/openvswitch/netdev.h
+++ b/include/openvswitch/netdev.h
@@ -61,6 +61,14 @@ struct netdev_stats {
uint64_t tx_heartbeat_errors;
uint64_t tx_window_errors;
+/* Detailed receive drops. */
+uint64_t rx_qos_drops;
+
+/* Detailed transmit drops. */
+uint64_t tx_qfull_drops;
+uint64_t tx_qos_drops;
+uint64_t tx_mtu_drops;
+
/* Extended statistics based on RFC2819. */
uint64_t rx_1_to_64_packets;
uint64_t rx_65_to_127_packets;
diff --git a/lib/dpctl.c b/lib/dpctl.c
index 9c4eb65..cdbf740 100644
--- a/lib/dpctl.c
+++ b/lib/dpctl.c
@@ -38,6 +38,7 @@
#include "flow.h"
#include "openvswitch/match.h"
#include "netdev.h"
+#include "netdev-provider.h"
#include "netlink.h"
#include "odp-util.h"
#include "openvswitch/ofpbuf.h"
@@ -683,6 +684,12 @@ show_dpif(struct dpif *dpif, struct dpctl_params *dpctl_p)
print_stat(dpctl_p, "RX packets:", s.rx_packets);
print_stat(dpctl_p, " errors:", s.rx_errors);
print_stat(dpctl_p, " dropped:", s.rx_dropped);
+if (dpctl_p->print_detailed_stats &&
+netdev->netdev_class->is_pmd) {
+dpctl_print(dpctl_p, " (");
+print_stat(dpctl_p, "qos:", s.rx_qos_drops);
+dpctl_print(dpctl_p, ") ");
+}
print_stat(dpctl_p, " overruns:", s.rx_over_errors);
print_stat(dpctl_p, " frame:", s.rx_frame_errors);
dpctl_print(dpctl_p, "\n");
@@ -690,6 +697,14 @@ show_dpif(struct dpif *dpif, struct dpctl_params *dpctl_p)
print_stat(dpctl_p, "TX packets:", s.tx_packets);
print_stat(dpctl_p, " errors:", s.tx_errors);
print_stat(dpctl_p, " dropped:", s.tx_dropped);
+if (dpctl_p->print_detailed_stats &&
+netdev->netdev_class->is_pmd) {
+dpctl_print(dpctl_p, " (");
+print_stat(dpctl_p, "queue_full:", s.tx_qfull_drops);
+print_stat(dpctl_p, " mtu_exceeded:", s.tx_mtu_drops);
+print_stat(dpctl_p, " qos:", s.tx_qos_drops);
+dpctl_print(dpctl_p, ") ");
+}
print_stat(dpctl_p, " aborted:", s.tx_aborted_errors);
print_stat(dpctl_p, " carrier:", s.tx_carrier_errors);
dpctl_print(dpctl_p, "\n");
@@ -2414,7 +2429,8 @@ static const struct dpctl_command all_commands[] = {
{ "del-if", "dp iface...", 2, INT_MAX, dpctl_del_if, DP_RW },
{ "set-if", "dp iface...", 2, INT_MAX, dpctl_set_if, DP_RW },
{ "dump-dps", "", 0, 0, dpctl_dump_dps, DP_RO },
-{ "show", "[dp...]", 0, INT_MAX, dpctl_show, DP_RO },
+{ "show", "[-s | --statistics [--details]] [dp...]", 0, \
+ INT_MAX, dpctl_show, DP_RO },
{ "dump-flows", "[dp] [filter=..] [type=..]",
0, 3, dpctl_dump_flows, DP_RO },
{ "add-flow", "[dp] flow actions", 2, 3, dpctl_add_flow, DP_RW },
@@ -2545,6 +2561,14 @@ dpctl_unixctl_handler(struct unixctl_conn *conn, int
argc, const char *argv[],
} else
[ovs-dev] [PATCH v2] Add support for DHCP option 15 - domain name
From: Maciej Józefczyk
For Openstack Internal DNS functionality we need
to provide support for domain_name option.
DHCP option 15 was previously used only in parser
tests and according to RFC it should be renamed to
domain_name [1].
This patch modifies its name in the tests from
'domain' to 'domain_name' and adds its support
to the code.
[1] https://tools.ietf.org/html/rfc2132#section-3.17
Signed-off-by: Maciej Józefczyk
---
ovn/lib/ovn-l7.h | 1 +
ovn/northd/ovn-northd.c| 1 +
ovn/ovn-nb.xml | 8
tests/oss-fuzz/expr_parse_target.c | 2 +-
tests/ovn.at | 8
tests/test-ovn.c | 2 +-
6 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/ovn/lib/ovn-l7.h b/ovn/lib/ovn-l7.h
index c24201ef0..362f537da 100644
--- a/ovn/lib/ovn-l7.h
+++ b/ovn/lib/ovn-l7.h
@@ -40,6 +40,7 @@ struct gen_opts_map {
#define DHCP_OPT_DNS_SERVER DHCP_OPTION("dns_server", 6, "ipv4")
#define DHCP_OPT_LOG_SERVER DHCP_OPTION("log_server", 7, "ipv4")
#define DHCP_OPT_LPR_SERVER DHCP_OPTION("lpr_server", 9, "ipv4")
+#define DHCP_OPT_DOMAIN_NAME DHCP_OPTION("domain_name", 15, "str")
#define DHCP_OPT_SWAP_SERVER DHCP_OPTION("swap_server", 16, "ipv4")
#define DHCP_OPT_POLICY_FILTER \
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index de0c06d4b..0b0a96a3a 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -8226,6 +8226,7 @@ static struct gen_opts_map supported_dhcp_opts[] = {
DHCP_OPT_BOOTFILE,
DHCP_OPT_PATH_PREFIX,
DHCP_OPT_TFTP_SERVER_ADDRESS,
+DHCP_OPT_DOMAIN_NAME,
};
static struct gen_opts_map supported_dhcpv6_opts[] = {
diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
index cbaa9495f..318379c1f 100644
--- a/ovn/ovn-nb.xml
+++ b/ovn/ovn-nb.xml
@@ -2355,6 +2355,14 @@
that matches with this requirement is option 66 (tftp_server).
+
+
+
+The DHCPv4 option code for this option is 15. This option
+specifies the domain name that client should use when
+resolving hostnames via the Domain Name System.
+
+
diff --git a/tests/oss-fuzz/expr_parse_target.c
b/tests/oss-fuzz/expr_parse_target.c
index 7416421b8..170186d9d 100644
--- a/tests/oss-fuzz/expr_parse_target.c
+++ b/tests/oss-fuzz/expr_parse_target.c
@@ -122,7 +122,7 @@ create_gen_opts(struct hmap *dhcp_opts, struct hmap
*dhcpv6_opts,
dhcp_opt_add(dhcp_opts, "dns_server", 6, "ipv4");
dhcp_opt_add(dhcp_opts, "log_server", 7, "ipv4");
dhcp_opt_add(dhcp_opts, "lpr_server", 9, "ipv4");
-dhcp_opt_add(dhcp_opts, "domain", 15, "str");
+dhcp_opt_add(dhcp_opts, "domain_name", 15, "str");
dhcp_opt_add(dhcp_opts, "swap_server", 16, "ipv4");
dhcp_opt_add(dhcp_opts, "policy_filter", 21, "ipv4");
dhcp_opt_add(dhcp_opts, "router_solicitation", 32, "ipv4");
diff --git a/tests/ovn.at b/tests/ovn.at
index 1231f4106..daf85a55d 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -1104,8 +1104,8 @@ put_arp(inport, arp.spa, arp.sha);
# put_dhcp_opts
reg1[0] = put_dhcp_opts(offerip = 1.2.3.4, router = 10.0.0.1);
encodes as
controller(userdata=00.00.00.02.00.00.00.00.00.01.de.10.00.00.00.40.01.02.03.04.03.04.0a.00.00.01,pause)
-reg2[5] =
put_dhcp_opts(offerip=10.0.0.4,router=10.0.0.1,netmask=255.255.254.0,mtu=1400,domain="ovn.org",wpad="https://example.org",bootfile_name="https://127.0.0.1/boot.ipxe",path_prefix="/tftpboot;);
-formats as reg2[5] = put_dhcp_opts(offerip = 10.0.0.4, router = 10.0.0.1,
netmask = 255.255.254.0, mtu = 1400, domain = "ovn.org", wpad =
"https://example.org;, bootfile_name = "https://127.0.0.1/boot.ipxe;,
path_prefix = "/tftpboot");
+reg2[5] =
put_dhcp_opts(offerip=10.0.0.4,router=10.0.0.1,netmask=255.255.254.0,mtu=1400,domain_name="ovn.org",wpad="https://example.org",bootfile_name="https://127.0.0.1/boot.ipxe",path_prefix="/tftpboot;);
+formats as reg2[5] = put_dhcp_opts(offerip = 10.0.0.4, router = 10.0.0.1,
netmask = 255.255.254.0, mtu = 1400, domain_name = "ovn.org", wpad =
"https://example.org;, bootfile_name = "https://127.0.0.1/boot.ipxe;,
path_prefix = "/tftpboot");
encodes as
controller(userdata=00.00.00.02.00.00.00.00.00.01.de.10.00.00.00.25.0a.00.00.04.03.04.0a.00.00.01.01.04.ff.ff.fe.00.1a.02.05.78.0f.07.6f.76.6e.2e.6f.72.67.fc.13.68.74.74.70.73.3a.2f.2f.65.78.61.6d.70.6c.65.2e.6f.72.67.43.1b.68.74.74.70.73.3a.2f.2f.31.32.37.2e.30.2e.30.2e.31.2f.62.6f.6f.74.2e.69.70.78.65.d2.09.2f.74.66.74.70.62.6f.6f.74,pause)
reg0[15] =
put_dhcp_opts(offerip=10.0.0.4,router=10.0.0.1,netmask=255.255.255.0,mtu=1400,ip_forward_enable=1,default_ttl=121,dns_server={8.8.8.8,7.7.7.7},classless_static_route={30.0.0.0/24,10.0.0.4,40.0.0.0/16,10.0.0.6,0.0.0.0/0,10.0.0.1},ethernet_encap=1,router_discovery=0,tftp_server_address={10.0.0.4,10.0.0.5});
formats as reg0[15] = put_dhcp_opts(offerip = 10.0.0.4, router = 10.0.0.1,
Re: [ovs-dev] [PATCH v10] Improved Packet Drop Statistics in OVS
Bleep bloop. Greetings Anju Thomas, 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: :804: new blank line at EOF. + warning: 1 line adds whitespace errors. Failed to merge in the changes. Patch failed at 0001 Improved Packet Drop Statistics in OVS 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
