Re: [ovs-dev] [PATCH v1] Fix crash due to multiple tnl push action
Thanks Ben. Regards Anju -Original Message- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Wednesday, January 23, 2019 5:24 AM To: Anju Thomas Cc: Stokes, Ian ; Lam, Tiago ; d...@openvswitch.org Subject: Re: [ovs-dev] [PATCH v1] Fix crash due to multiple tnl push action OK. I applied the first part to all relevant branches. On Mon, Jan 21, 2019 at 04:06:26AM +, Anju Thomas wrote: > Hi Ben/Ian, > I understand that the second part of the patch needs more review. But > do you think we can atleast merge the first part of this viz > https://mail.openvswitch.org/pipermail/ovs-dev/2018-May/346649.html so that > to crash and more importantly silent leaks . We can widely review the other > part of the code as it might require more indepth testing and review. > > What are your suggestions ? > > Regards > Anju > > -Original Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Thursday, January 17, 2019 11:39 PM > To: Stokes, Ian > Cc: Lam, Tiago ; Anju Thomas > ; d...@openvswitch.org > Subject: Re: [ovs-dev] [PATCH v1] Fix crash due to multiple tnl push > action > > On Wed, Jan 16, 2019 at 11:38:38AM +, Stokes, Ian wrote: > > > On 16/01/2019 09:30, Anju Thomas wrote: > > > > > > > > Hi Folks, > > > > > > > > Are these changes planned to be merged as well? > > > > > > > > Regards > > > > Anju > > > > > > Hi Anju, > > > > > > Unfortunately, no. An RFC based on the below was proposed to the > > > mailing list here [1], but no discussion / comments happened after > > > that. Further discussion and testing would be needed to move this > > > forward... > > > > > > > I wasn't aware of this tbh. It seems like a bug fix so I believe it would > > be eligible to be merged for the 2.11 release a(and possibly backported > > also). > > > > As it manipulates the dp packets functionality it would need wider testing > > and discussion among the community. > > > > It won't make it upstream this week before we cut for 2.11 I would think > > but there is 4 weeks allowed until release where bug fixes are allowed. If > > further work continues it could be merged within that window or afterwards > > and backported? > > Bug fixes are welcomed at any time, pre- or post-release. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] compat: Fixup ipv6 fragmentation on 4.9.135+ kernels
On Tue, Jan 22, 2019 at 05:14:05PM -0800, Gregory Rose wrote:
>
> On 1/22/2019 5:09 PM, Ben Pfaff wrote:
> > On Tue, Jan 22, 2019 at 05:08:38PM -0800, Ben Pfaff wrote:
> > > On Tue, Jan 22, 2019 at 04:38:24PM -0800, Yi-Hung Wei wrote:
> > > > On Thu, Jan 10, 2019 at 2:09 PM Greg Rose wrote:
> > > > > Upstream commit 648700f76b03 ("inet: frags: use rhashtables...")
> > > > > changed
> > > > > how ipv6 fragmentation is implemented. This patch was backported to
> > > > > the upstream stable 4.9.x kernel starting at 4.9.135.
> > > > >
> > > > > This patch creates the compatibility layer changes required to both
> > > > > compile and also operate correctly with ipv6 fragmentation on these
> > > > > kernels. Check if the inet_frags 'rnd' field is present to key on
> > > > > whether the upstream patch is present. Also update Travis to the
> > > > > latest 4.9 kernel release so that this patch is compile tested.
> > > > >
> > > > > Passes Travis:
> > > > > https://travis-ci.org/gvrose8192/ovs-experimental/builds/478033409
> > > > >
> > > > > Cc: William Tu
> > > > > Cc: Yi-Hung Wei
> > > > > Cc: Yifeng Sun
> > > > > Signed-off-by: Greg Rose
> > > > > ---
> > > > Thanks for all the explanation in the follow up e-mails. This patch
> > > > looks good to me now.
> > > >
> > > > Acked-by: Yi-Hung Wei
> > > I applied this patch to master.
> > and branch-2.11; let me know if it should be backported further.
>
> I think 2.9 and 2.10 as well.
It gave me a patch conflict on 2.10, would you mind posting a manual
backport?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] compat: Fixup ipv6 fragmentation on 4.9.135+ kernels
On 1/22/2019 5:22 PM, Ben Pfaff wrote:
On Tue, Jan 22, 2019 at 05:14:05PM -0800, Gregory Rose wrote:
On 1/22/2019 5:09 PM, Ben Pfaff wrote:
On Tue, Jan 22, 2019 at 05:08:38PM -0800, Ben Pfaff wrote:
On Tue, Jan 22, 2019 at 04:38:24PM -0800, Yi-Hung Wei wrote:
On Thu, Jan 10, 2019 at 2:09 PM Greg Rose wrote:
Upstream commit 648700f76b03 ("inet: frags: use rhashtables...") changed
how ipv6 fragmentation is implemented. This patch was backported to
the upstream stable 4.9.x kernel starting at 4.9.135.
This patch creates the compatibility layer changes required to both
compile and also operate correctly with ipv6 fragmentation on these
kernels. Check if the inet_frags 'rnd' field is present to key on
whether the upstream patch is present. Also update Travis to the
latest 4.9 kernel release so that this patch is compile tested.
Passes Travis:
https://travis-ci.org/gvrose8192/ovs-experimental/builds/478033409
Cc: William Tu
Cc: Yi-Hung Wei
Cc: Yifeng Sun
Signed-off-by: Greg Rose
---
Thanks for all the explanation in the follow up e-mails. This patch
looks good to me now.
Acked-by: Yi-Hung Wei
I applied this patch to master.
and branch-2.11; let me know if it should be backported further.
I think 2.9 and 2.10 as well.
It gave me a patch conflict on 2.10, would you mind posting a manual
backport?
Sure, will do. I'll also look at 2.9.
Thanks,
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] compat: Fixup ipv6 fragmentation on 4.9.135+ kernels
On 1/22/2019 5:09 PM, Ben Pfaff wrote:
On Tue, Jan 22, 2019 at 05:08:38PM -0800, Ben Pfaff wrote:
On Tue, Jan 22, 2019 at 04:38:24PM -0800, Yi-Hung Wei wrote:
On Thu, Jan 10, 2019 at 2:09 PM Greg Rose wrote:
Upstream commit 648700f76b03 ("inet: frags: use rhashtables...") changed
how ipv6 fragmentation is implemented. This patch was backported to
the upstream stable 4.9.x kernel starting at 4.9.135.
This patch creates the compatibility layer changes required to both
compile and also operate correctly with ipv6 fragmentation on these
kernels. Check if the inet_frags 'rnd' field is present to key on
whether the upstream patch is present. Also update Travis to the
latest 4.9 kernel release so that this patch is compile tested.
Passes Travis:
https://travis-ci.org/gvrose8192/ovs-experimental/builds/478033409
Cc: William Tu
Cc: Yi-Hung Wei
Cc: Yifeng Sun
Signed-off-by: Greg Rose
---
Thanks for all the explanation in the follow up e-mails. This patch
looks good to me now.
Acked-by: Yi-Hung Wei
I applied this patch to master.
and branch-2.11; let me know if it should be backported further.
I think 2.9 and 2.10 as well.
Thanks Ben!
- Greg
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] compat: Fixup ipv6 fragmentation on 4.9.135+ kernels
On Tue, Jan 22, 2019 at 05:08:38PM -0800, Ben Pfaff wrote:
> On Tue, Jan 22, 2019 at 04:38:24PM -0800, Yi-Hung Wei wrote:
> > On Thu, Jan 10, 2019 at 2:09 PM Greg Rose wrote:
> > >
> > > Upstream commit 648700f76b03 ("inet: frags: use rhashtables...") changed
> > > how ipv6 fragmentation is implemented. This patch was backported to
> > > the upstream stable 4.9.x kernel starting at 4.9.135.
> > >
> > > This patch creates the compatibility layer changes required to both
> > > compile and also operate correctly with ipv6 fragmentation on these
> > > kernels. Check if the inet_frags 'rnd' field is present to key on
> > > whether the upstream patch is present. Also update Travis to the
> > > latest 4.9 kernel release so that this patch is compile tested.
> > >
> > > Passes Travis:
> > > https://travis-ci.org/gvrose8192/ovs-experimental/builds/478033409
> > >
> > > Cc: William Tu
> > > Cc: Yi-Hung Wei
> > > Cc: Yifeng Sun
> > > Signed-off-by: Greg Rose
> > > ---
> > Thanks for all the explanation in the follow up e-mails. This patch
> > looks good to me now.
> >
> > Acked-by: Yi-Hung Wei
>
> I applied this patch to master.
and branch-2.11; let me know if it should be backported further.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] compat: Fixup ipv6 fragmentation on 4.9.135+ kernels
On Tue, Jan 22, 2019 at 04:38:24PM -0800, Yi-Hung Wei wrote:
> On Thu, Jan 10, 2019 at 2:09 PM Greg Rose wrote:
> >
> > Upstream commit 648700f76b03 ("inet: frags: use rhashtables...") changed
> > how ipv6 fragmentation is implemented. This patch was backported to
> > the upstream stable 4.9.x kernel starting at 4.9.135.
> >
> > This patch creates the compatibility layer changes required to both
> > compile and also operate correctly with ipv6 fragmentation on these
> > kernels. Check if the inet_frags 'rnd' field is present to key on
> > whether the upstream patch is present. Also update Travis to the
> > latest 4.9 kernel release so that this patch is compile tested.
> >
> > Passes Travis:
> > https://travis-ci.org/gvrose8192/ovs-experimental/builds/478033409
> >
> > Cc: William Tu
> > Cc: Yi-Hung Wei
> > Cc: Yifeng Sun
> > Signed-off-by: Greg Rose
> > ---
> Thanks for all the explanation in the follow up e-mails. This patch
> looks good to me now.
>
> Acked-by: Yi-Hung Wei
I applied this patch to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] compat: Fixup ipv6 fragmentation on 4.9.135+ kernels
On 1/22/2019 4:38 PM, Yi-Hung Wei wrote:
On Thu, Jan 10, 2019 at 2:09 PM Greg Rose wrote:
Upstream commit 648700f76b03 ("inet: frags: use rhashtables...") changed
how ipv6 fragmentation is implemented. This patch was backported to
the upstream stable 4.9.x kernel starting at 4.9.135.
This patch creates the compatibility layer changes required to both
compile and also operate correctly with ipv6 fragmentation on these
kernels. Check if the inet_frags 'rnd' field is present to key on
whether the upstream patch is present. Also update Travis to the
latest 4.9 kernel release so that this patch is compile tested.
Passes Travis:
https://travis-ci.org/gvrose8192/ovs-experimental/builds/478033409
Cc: William Tu
Cc: Yi-Hung Wei
Cc: Yifeng Sun
Signed-off-by: Greg Rose
---
Thanks for all the explanation in the follow up e-mails. This patch
looks good to me now.
Acked-by: Yi-Hung Wei
Thanks!
This should probably be backported to 2.9 and 2.10.
- Greg
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] ovn: Add pkg-config support via libovn.pc.
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: ERROR: Author 竹內宏輝 Hiroki Takeuchi needs to sign off. WARNING: Unexpected sign-offs from developers who are not authors or co-authors or committers: Hiroki Takeuchi Lines checked: 61, Warnings: 1, Errors: 1 Please check this out. If you feel there has been an error, please email acon...@bytheb.org Thanks, 0-day Robot ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] good evening!
Dear,
write me from your private email address here {(shqin...@gmail.com)} for
future communication and details.
Regards,
Shiq
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] compat: Fixup ipv6 fragmentation on 4.9.135+ kernels
On Thu, Jan 10, 2019 at 2:09 PM Greg Rose wrote:
>
> Upstream commit 648700f76b03 ("inet: frags: use rhashtables...") changed
> how ipv6 fragmentation is implemented. This patch was backported to
> the upstream stable 4.9.x kernel starting at 4.9.135.
>
> This patch creates the compatibility layer changes required to both
> compile and also operate correctly with ipv6 fragmentation on these
> kernels. Check if the inet_frags 'rnd' field is present to key on
> whether the upstream patch is present. Also update Travis to the
> latest 4.9 kernel release so that this patch is compile tested.
>
> Passes Travis:
> https://travis-ci.org/gvrose8192/ovs-experimental/builds/478033409
>
> Cc: William Tu
> Cc: Yi-Hung Wei
> Cc: Yifeng Sun
> Signed-off-by: Greg Rose
> ---
Thanks for all the explanation in the follow up e-mails. This patch
looks good to me now.
Acked-by: Yi-Hung Wei
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] ovn: Add pkg-config support via libovn.pc.
From: 竹內宏輝 Hiroki Takeuchi
Submitted-at: https://github.com/openvswitch/ovs/pull/270
Signed-off-by: Hiroki Takeuchi
---
I'm sending this patch as a squashed version of what was submitted at
Github. I know that pkg-config is somewhat controversial, so I'd like to
hear what the denizens of ovs-dev have to say about including a libovn.pc.
Thanks,
Ben.
configure.ac | 1 +
ovn/lib/automake.mk | 3 +++
ovn/lib/libovn.pc.in | 11 +++
3 files changed, 15 insertions(+)
create mode 100644 ovn/lib/libovn.pc.in
diff --git a/configure.ac b/configure.ac
index 505e3d041e93..473454265532 100644
--- a/configure.ac
+++ b/configure.ac
@@ -201,6 +201,7 @@ AC_CONFIG_FILES(lib/libopenvswitch.pc)
AC_CONFIG_FILES(lib/libsflow.pc)
AC_CONFIG_FILES(ofproto/libofproto.pc)
AC_CONFIG_FILES(ovsdb/libovsdb.pc)
+AC_CONFIG_FILES(ovn/lib/libovn.pc)
AC_CONFIG_FILES(include/openvswitch/version.h)
dnl This makes sure that include/openflow gets created in the build directory.
diff --git a/ovn/lib/automake.mk b/ovn/lib/automake.mk
index 6178fc2d5aa4..cb216f626293 100644
--- a/ovn/lib/automake.mk
+++ b/ovn/lib/automake.mk
@@ -24,6 +24,9 @@ nodist_ovn_lib_libovn_la_SOURCES = \
ovn/lib/ovn-sb-idl.c \
ovn/lib/ovn-sb-idl.h
+pkgconfig_DATA += \
+ ovn/lib/libovn.pc
+
# ovn-sb IDL
OVSIDL_BUILT += \
ovn/lib/ovn-sb-idl.c \
diff --git a/ovn/lib/libovn.pc.in b/ovn/lib/libovn.pc.in
new file mode 100644
index ..6d9b22be6568
--- /dev/null
+++ b/ovn/lib/libovn.pc.in
@@ -0,0 +1,11 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libovn
+Description: Open Virtual Network for Open vSwitch
+Version: @VERSION@
+Libs: -L${libdir} -lovn
+Libs.private: @LIBS@
+Cflags: -I${includedir}/ovn
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v6] Improved Packet Drop Statistics in OVS
On Mon, Jan 21, 2019 at 07:01:33AM +, Anju Thomas wrote: > On Thu, Jan 17, 2019 at 04:49:20AM +, 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. > > Thanks for the patch! I agree with your motivations--it is useful to > understand why packets are dropped. I have some comments to add to Ilya's. > > It looks like the drop actions that this formats in > format_odp_drop_action() can't necessarily be parsed by > odp_actions_from_string(). Usually we expect this. (Probably the syntax > should be adjusted to make parsing more straightforward.) > odp_actions_from string is used to convert string to action for > parsing .But we are using the drop action reason only fo display. We do not > want to provide an option for its parsing. Is my understanding correct. Why not? Ordinarily, anything that can be output can be input. It is useful for testing to be able to input datapath actions. > It looks like xlate_error maps one-to-one to drop reasons (except why is > XLATE_FORWARDING_DISABLED mapped to OVS_DROP_REASON_MAX?), so do we really > want different enumerations? Mapping back and forth is a bit of a slog, and > there's already a way to translate xlate_errors to strings. > > .We just kept it separate for better code readability and also that > XLATE_** error were more in the ofproto layer and we wanted something in the > datapath . If you believe that that is not justified compared to the slogging > then I will modify this . What do you say ? I'd leave them the same for now, until there's a need for them to be different. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH V2 0/2] Do not rewrite fields with the same values as
On Fri, Jan 11, 2019 at 08:28:57AM +0200, Eli Britstein wrote: > Hi > > This patch set avoids unnecessary rewrite actions to fields with the > same values as matched on. > > Patch 1 is a pre-step by defining ovs key structs using macros > > Patch 2 avoids the unnecessary rewrites and adapts the tests accordingly I like the goal of the patch, but it makes openvswitch.h unreadable and completely different from Linux upstream. One of the goals of that "sed" script is to avoid having it be different from upstream. I think that we should come up with a way to do this that avoids the problem. Offhand, I can think of a couple of ways: - Write a script that parses openvswitch.h in a simple way and extracts the needed information into a file that can be #included. - Just list the relevant field names in odp-util.c in the relevant functions. From field names, it's easy to get offsets (with offsetof) and sizes (MEMBER_SIZEOF). It might be problematic to keep these in sync if the structures changed, but they will not because the Linux ABI is stable. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [patch v4 1/2] conntrack: fix ftp ipv4 address substitution.
I would like to wait for David to return, so please hold off for now. On 1/22/19, 3:58 PM, "ovs-dev-boun...@openvswitch.org on behalf of Ben Pfaff" wrote: It looks like you have some changes to both patches, will you post a v5? Is this series otherwise ready to go (do you have buy-in from David for the revisions)? ___ dev mailing list d...@openvswitch.org https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-devdata=02%7C01%7Cdball%40vmware.com%7C4f0c335b794d455654a608d680c58eae%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636837983358980395sdata=vSTbqptNyV15qdBXKJpU898QODlJKF0uAo6tsXaUyBY%3Dreserved=0 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH V2] rhel: bug fix upgrade path in kmod fedora spec file
Flavio, can you give an opinion on this?
Thanks,
Ben.
On Tue, Jan 22, 2019 at 03:02:30PM -0800, Greg Rose wrote:
> From: Martin Xu
>
> This patch removes the "Conflicts" tag and adds "Obsoletes" tag.
>
> With the conflicts tag, when a user attempts to install or upgrade with
> the same version as already installed, the conflict kicks in. Otherwise,
> such is allowed with --replacepkgs.
>
> Obsoletes is needed for the upgrade path from kmod-openvswitch to
> openvswitch-kmod.
>
> Fixes: 22c33c3039 (rhel: support kmod build against mulitple kernel
> versions, fedora)
>
> VMware-BZ: #2249788
>
> Signed-off-by: Martin Xu
> Signed-off-by: Greg Rose
> CC: Flavio Leitner
> CC: Yi-Hung Wei
> CC: Yifeng Sun
> CC: Zak Whittington
> CC: Ben Pfaff
> ---
> v1->v2: adds "Obsoletes" tag needed for upgrade after renaming
> adds more reviewers
> v2-v3: Incorporate Flavio's recommendation to check version and
>release values.
> ---
> rhel/openvswitch-kmod-fedora.spec.in | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/rhel/openvswitch-kmod-fedora.spec.in
> b/rhel/openvswitch-kmod-fedora.spec.in
> index 8d54fd7..9a4c489 100644
> --- a/rhel/openvswitch-kmod-fedora.spec.in
> +++ b/rhel/openvswitch-kmod-fedora.spec.in
> @@ -33,7 +33,7 @@ Source: openvswitch-%{version}.tar.gz
> #Source1: openvswitch-init
> Buildroot: /tmp/openvswitch-xen-rpm
> Provides: kmod-openvswitch
> -Conflicts: kmod-openvswitch
> +Obsoletes: kmod-openvswitch < %{version}-%{release}
>
> %description
> Open vSwitch provides standard network bridging functions augmented with
> --
> 1.8.3.1
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] rhel: bug fix upgrade path in kmod fedora spec file
Bleep bloop. Greetings Greg Rose, 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: Unexpected sign-offs from developers who are not authors or co-authors or committers: Greg Rose 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] [branch-2.9 1/3] conntrack: fix tcp seq adjustments when mangling commands.
Thanks for the backport. I applied this series to branch-2.9. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [patch v4 1/2] conntrack: fix ftp ipv4 address substitution.
It looks like you have some changes to both patches, will you post a v5? Is this series otherwise ready to go (do you have buy-in from David for the revisions)? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1] Fix crash due to multiple tnl push action
OK. I applied the first part to all relevant branches. On Mon, Jan 21, 2019 at 04:06:26AM +, Anju Thomas wrote: > Hi Ben/Ian, > I understand that the second part of the patch needs more review. But do you > think we can atleast merge the first part of this viz > https://mail.openvswitch.org/pipermail/ovs-dev/2018-May/346649.html so that > to crash and more importantly silent leaks . We can widely review the other > part of the code as it might require more indepth testing and review. > > What are your suggestions ? > > Regards > Anju > > -Original Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Thursday, January 17, 2019 11:39 PM > To: Stokes, Ian > Cc: Lam, Tiago ; Anju Thomas ; > d...@openvswitch.org > Subject: Re: [ovs-dev] [PATCH v1] Fix crash due to multiple tnl push action > > On Wed, Jan 16, 2019 at 11:38:38AM +, Stokes, Ian wrote: > > > On 16/01/2019 09:30, Anju Thomas wrote: > > > > > > > > Hi Folks, > > > > > > > > Are these changes planned to be merged as well? > > > > > > > > Regards > > > > Anju > > > > > > Hi Anju, > > > > > > Unfortunately, no. An RFC based on the below was proposed to the > > > mailing list here [1], but no discussion / comments happened after > > > that. Further discussion and testing would be needed to move this > > > forward... > > > > > > > I wasn't aware of this tbh. It seems like a bug fix so I believe it would > > be eligible to be merged for the 2.11 release a(and possibly backported > > also). > > > > As it manipulates the dp packets functionality it would need wider testing > > and discussion among the community. > > > > It won't make it upstream this week before we cut for 2.11 I would think > > but there is 4 weeks allowed until release where bug fixes are allowed. If > > further work continues it could be merged within that window or afterwards > > and backported? > > Bug fixes are welcomed at any time, pre- or post-release. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] datapath: return -EEXIST if inet6_add_protocol fails
Our code to determine whether receive functionality will work with
ip6 gre depends on the return of -EEXIST but inet6_add_protocol()
returns a -1 on failure to grab the pointer via a cmpxchg op. Just
set the error return to -EEXIST to help out the vport init function.
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-January/048090.html
Reported-by: Ken Ajiro
Signed-off-by: Greg Rose
---
datapath/linux/compat/ip6_gre.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/datapath/linux/compat/ip6_gre.c b/datapath/linux/compat/ip6_gre.c
index 1827852..2ffdda5 100644
--- a/datapath/linux/compat/ip6_gre.c
+++ b/datapath/linux/compat/ip6_gre.c
@@ -2802,6 +2802,13 @@ int rpl_ip6gre_init(void)
if (err < 0) {
pr_info("%s: can't add protocol\n", __func__);
unregister_pernet_device(_net_ops);
+ /*
+* inet6_add_protocol will return a -1 if it fails
+* to grab the pointer but the vport initialization
+* expects a return value of -EEXIST. Set err to
+* -EEXIST here to ensure proper handling.
+*/
+ err = -EEXIST;
goto ip6_gre_loaded;
}
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 0/2] travis: misc. improvements
On Mon, Jan 21, 2019 at 01:05:24PM -0500, Aaron Conole wrote: > Following are some quick changes to improve the travis testing. Thanks, applied to master. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH V2] rhel: bug fix upgrade path in kmod fedora spec file
From: Martin Xu
This patch removes the "Conflicts" tag and adds "Obsoletes" tag.
With the conflicts tag, when a user attempts to install or upgrade with
the same version as already installed, the conflict kicks in. Otherwise,
such is allowed with --replacepkgs.
Obsoletes is needed for the upgrade path from kmod-openvswitch to
openvswitch-kmod.
Fixes: 22c33c3039 (rhel: support kmod build against mulitple kernel
versions, fedora)
VMware-BZ: #2249788
Signed-off-by: Martin Xu
Signed-off-by: Greg Rose
CC: Flavio Leitner
CC: Yi-Hung Wei
CC: Yifeng Sun
CC: Zak Whittington
CC: Ben Pfaff
---
v1->v2: adds "Obsoletes" tag needed for upgrade after renaming
adds more reviewers
v2-v3: Incorporate Flavio's recommendation to check version and
release values.
---
rhel/openvswitch-kmod-fedora.spec.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rhel/openvswitch-kmod-fedora.spec.in
b/rhel/openvswitch-kmod-fedora.spec.in
index 8d54fd7..9a4c489 100644
--- a/rhel/openvswitch-kmod-fedora.spec.in
+++ b/rhel/openvswitch-kmod-fedora.spec.in
@@ -33,7 +33,7 @@ Source: openvswitch-%{version}.tar.gz
#Source1: openvswitch-init
Buildroot: /tmp/openvswitch-xen-rpm
Provides: kmod-openvswitch
-Conflicts: kmod-openvswitch
+Obsoletes: kmod-openvswitch < %{version}-%{release}
%description
Open vSwitch provides standard network bridging functions augmented with
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] seq: Correct example in comment.
On Tue, Jan 22, 2019 at 12:52:56PM +0300, Ilya Maximets wrote: > On 22.01.2019 4:14, Ben Pfaff wrote: > > It was deceptive for the example to imply that a seq can be declared > > directly, because the API only allows for creating a new one on the heap. > > > > Signed-off-by: Ben Pfaff > > Thanks. > Maybe you can additionally fix the C99-style comment here to not use > a bad style inside the example. > > Anyway, > Acked-by: Ilya Maximets Thanks, I applied this to master. It's tricky to avoid C99 comments in code samples inside regular C comments, because C comments don't nest. Do you have a suggestion on how to do it? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1] rhel: retain OVS_CTL_OPTS for systemd service files
Aaron,
This patch seems to have fallen through the cracks. Would you mind
giving this a review? Martin is no
longer with VMware so I will be following up on this patch.
Thanks,
- Greg
On 9/14/2018 12:49 PM, Martin Xu wrote:
OVS init.d script calls ovs-ctl with $OVS_CTL_OPTS defined in the
config file. This variable is replaced by OPTIONS in systemd service
files. This patch addes $OVS_CTL_OPTS back to be passed along with $OPTIONS
for backward compatibility.
VMware-BZ: #2036847
Signed-off-by: Martin Xu
CC: Aaron Conole
---
rhel/usr_lib_systemd_system_ovs-vswitchd.service.in | 4 ++--
rhel/usr_lib_systemd_system_ovsdb-server.service | 4 ++--
rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template | 5 +
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
index 11b34c6..e4dbdf3 100644
--- a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
+++ b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
@@ -21,10 +21,10 @@ ExecStartPre=-/usr/bin/chmod 0775 /dev/hugepages
ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \
--no-ovsdb-server --no-monitor --system-id=random \
${OVSUSER} \
- start $OPTIONS
+ start $OPTIONS $OVS_CTL_OPTS
ExecStop=/usr/share/openvswitch/scripts/ovs-ctl --no-ovsdb-server stop
ExecReload=/usr/share/openvswitch/scripts/ovs-ctl --no-ovsdb-server \
--no-monitor --system-id=random \
${OVSUSER} \
- restart $OPTIONS
+ restart $OPTIONS $OVS_CTL_OPTS
TimeoutSec=300
diff --git a/rhel/usr_lib_systemd_system_ovsdb-server.service
b/rhel/usr_lib_systemd_system_ovsdb-server.service
index 70da1ec..09f946b 100644
--- a/rhel/usr_lib_systemd_system_ovsdb-server.service
+++ b/rhel/usr_lib_systemd_system_ovsdb-server.service
@@ -16,10 +16,10 @@ EnvironmentFile=-/run/openvswitch/useropts
ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \
--no-ovs-vswitchd --no-monitor --system-id=random \
${OVSUSER} \
- start $OPTIONS
+ start $OPTIONS $OVS_CTL_OPTS
ExecStop=/usr/share/openvswitch/scripts/ovs-ctl --no-ovs-vswitchd stop
ExecReload=/usr/share/openvswitch/scripts/ovs-ctl --no-ovs-vswitchd \
${OVSUSER} \
- --no-monitor restart $OPTIONS
+ --no-monitor restart $OPTIONS $OVS_CTL_OPTS
RuntimeDirectory=openvswitch
RuntimeDirectoryMode=0755
diff --git a/rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template
b/rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template
index 9364454..0ce5b6b 100644
--- a/rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template
+++ b/rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template
@@ -23,5 +23,10 @@
#
OPTIONS=""
+# OVS_CTL_OPTS: Extra options to pass along with OPTIONS to ovs-ctl.
+# This flag is retained for backward compatibility. For example,
+# user can specify --ovs-vswitchd-wrapper=valgrind.
+# OVS_CTL_OPTS=
+
# Uncomment and set the OVS User/Group value
#OVS_USER_ID="openvswitch:openvswitch"
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [patch v4 2/2] conntrack: Fix max size for inet_ntop() call.
On Mon, Jan 21, 2019 at 9:27 PM Darrell Ball wrote:
> The call to inet_ntop() in repl_ftp_v6_addr() is 1 short to handle
> the maximum possible V6 address size for v4 mapping case.
>
> Found by inspection.
>
>
Should have a fixes tag:
Fixes: bd5e81a0e596 ("Userspace Datapath: Add ALG infra and FTP.")
> Signed-off-by: Darrell Ball
> ---
> lib/conntrack.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/conntrack.c b/lib/conntrack.c
> index 6b66750..922a58c 100644
> --- a/lib/conntrack.c
> +++ b/lib/conntrack.c
> @@ -3161,7 +3161,7 @@ repl_ftp_v6_addr(struct dp_packet *pkt, struct
> ct_addr v6_addr_rep,
>
> char v6_addr_str[IPV6_SCAN_LEN] = {0};
> ovs_assert(inet_ntop(AF_INET6, _addr_rep.ipv6_aligned, v6_addr_str,
> - IPV6_SCAN_LEN - 1));
> + sizeof v6_addr_str));
> modify_packet(pkt, ftp_data_start + addr_offset_from_ftp_data_start,
>addr_size, v6_addr_str, strlen(v6_addr_str),
>orig_used_size);
> --
> 1.9.1
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [patch v4 1/2] conntrack: fix ftp ipv4 address substitution.
On Mon, Jan 21, 2019 at 9:27 PM Darrell Ball wrote:
> When replacing the ipv4 address in repl_ftp_v4_addr(), the remaining size
> was incorrectly calculated which could lead to the wrong replacement
> adjustment.
>
> This goes unnoticed most of the time, unless you choose carefully your
> initial and replacement addresses.
>
> Example fail address combination with 10.1.1.200 DNAT'd to 10.1.100.1.
>
> Fix this by doing something similar to V6 and also splicing out common
> code for better coverage and maintainability.
>
> A test is updated to exercise different initial and replacement addresses
> and another test is added.
>
> Fixes: bd5e81a0e596 ("Userspace Datapath: Add ALG infra and FTP.")
> Co-authored-by: David Marchand
> Signed-off-by: David Marchand
> Signed-off-by: Darrell Ball
> ---
>
> v4: Fix bug in call to inet_ntop() in repl_ftp_v4_addr().
> v3: Make V4 and V6 code paths more common.
> v2: Minimum alternative patch; also add tests.
>
> lib/conntrack.c | 118
> +++-
> tests/system-traffic.at | 74 +++---
> 2 files changed, 123 insertions(+), 69 deletions(-)
>
> diff --git a/lib/conntrack.c b/lib/conntrack.c
> index f732b9e..6b66750 100644
> --- a/lib/conntrack.c
> +++ b/lib/conntrack.c
> @@ -136,7 +136,7 @@ expectation_lookup(struct hmap *alg_expectations,
> const struct conn_key *key,
> static int
> repl_ftp_v4_addr(struct dp_packet *pkt, ovs_be32 v4_addr_rep,
> char *ftp_data_v4_start,
> - size_t addr_offset_from_ftp_data_start);
> + size_t addr_offset_from_ftp_data_start, size_t
> addr_size);
>
> static enum ftp_ctl_pkt
> process_ftp_ctl_v4(struct conntrack *ct,
> @@ -144,7 +144,8 @@ process_ftp_ctl_v4(struct conntrack *ct,
> const struct conn *conn_for_expectation,
> ovs_be32 *v4_addr_rep,
> char **ftp_data_v4_start,
> - size_t *addr_offset_from_ftp_data_start);
> + size_t *addr_offset_from_ftp_data_start,
> + size_t *addr_size);
>
> static enum ftp_ctl_pkt
> detect_ftp_ctl_type(const struct conn_lookup_ctx *ctx,
> @@ -2771,13 +2772,6 @@ expectation_create(struct conntrack *ct, ovs_be16
> dst_port,
> ct_rwlock_unlock(>resources_lock);
> }
>
> -static uint8_t
> -get_v4_byte_be(ovs_be32 v4_addr, uint8_t index)
> -{
> -uint8_t *byte_ptr = (OVS_FORCE uint8_t *) _addr;
> -return byte_ptr[index];
> -}
> -
> static void
> replace_substring(char *substr, uint8_t substr_size,
>uint8_t total_size, char *rep_str,
> @@ -2788,51 +2782,56 @@ replace_substring(char *substr, uint8_t
> substr_size,
> memcpy(substr, rep_str, rep_str_size);
> }
>
> +static void
> +repl_bytes(char *str, char c1, char c2)
> +{
> +while (*str) {
> +if (*str == c1) {
> +*str = c2;
> +}
> +str++;
> +}
> +}
> +
> +static void
> +modify_packet(struct dp_packet *pkt, char *pkt_str, size_t size,
> + char *repl_str, size_t repl_size,
> + uint32_t orig_used_size)
> +{
> +replace_substring(pkt_str, size,
> + (const char *) dp_packet_tail(pkt) - pkt_str,
> + repl_str, repl_size);
> +dp_packet_set_size(pkt, orig_used_size + (int) repl_size - (int)
> size);
> +}
> +
> /* Replace IPV4 address in FTP message with NATed address. */
> static int
> repl_ftp_v4_addr(struct dp_packet *pkt, ovs_be32 v4_addr_rep,
> char *ftp_data_start,
> - size_t addr_offset_from_ftp_data_start)
> + size_t addr_offset_from_ftp_data_start,
> + size_t addr_size OVS_UNUSED)
>
'OVS_UNUSED' above will be removed.
> {
> enum { MAX_FTP_V4_NAT_DELTA = 8 };
>
> /* Do conservative check for pathological MTU usage. */
> uint32_t orig_used_size = dp_packet_size(pkt);
> -uint16_t allocated_size = dp_packet_get_allocated(pkt);
> -if (orig_used_size + MAX_FTP_V4_NAT_DELTA > allocated_size) {
> +if (orig_used_size + MAX_FTP_V4_NAT_DELTA >
> +dp_packet_get_allocated(pkt)) {
> +
> static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 5);
> -VLOG_WARN_RL(, "Unsupported effective MTU %u used with FTP",
> - allocated_size);
> +VLOG_WARN_RL(, "Unsupported effective MTU %u used with FTP V4",
> + dp_packet_get_allocated(pkt));
> return 0;
> }
>
> -size_t remain_size = tcp_payload_length(pkt) -
> - addr_offset_from_ftp_data_start;
> -int overall_delta = 0;
> -char *byte_str = ftp_data_start + addr_offset_from_ftp_data_start;
> -
> -/* Replace the existing IPv4 address by the new one. */
> -for (uint8_t i = 0; i < 4; i++) {
> -/* Find the end of the string for this octet. */
> -char *next_delim = memchr(byte_str, ',', 4);
> -
Re: [ovs-dev] [PATCH] datapath-windows: Add support for 'OVS_KEY_ATTR_ENCAP' key attribute.
> -Mesaj original- > De la: ovs-dev-boun...@openvswitch.org boun...@openvswitch.org> În numele Anand Kumar > Trimis: Friday, January 11, 2019 2:45 AM > Către: d...@openvswitch.org > Subiect: [ovs-dev] [PATCH] datapath-windows: Add support for > 'OVS_KEY_ATTR_ENCAP' key attribute. > > Add a new structure in l2 header to accomodate vlan header, based of > commit "d7efce7beff25052bd9083419200e1a47f0d6066 > datapath: 802.1AD Flow handling, actions, vlan parsing, netlink attributes" > > Also reset vlan header in flow key, after deleting vlan tag from nbl > > With this change a sample vlan flow would look like, > eth(src=0a:ea:8a:24:03:86,dst=0a:cd:fa:4d:15:5c),in_port(3),eth_type(0x8100 > ), > vlan(vid=2239,pcp=0),encap(eth_type(0x0800),ipv4(src=13.12.11.149,dst=13. > 12.11.107, > proto=1,tos=0,ttl=128,frag=no),icmp(type=8,code=0)) > > Signed-off-by: Anand Kumar > --- > datapath-windows/ovsext/Actions.c| 3 + > datapath-windows/ovsext/DpInternal.h | 12 +++- > datapath-windows/ovsext/Flow.c | 126 > +++ > datapath-windows/ovsext/User.c | 19 ++ > 4 files changed, 144 insertions(+), 16 deletions(-) > [Alin Serdean] Thanks for the patch! Acked-by: Alin Gabriel Serdean ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] WhatsApp cómo poderosa herramienta
Cursos TOP - Webinar Interactivo – Miércoles 30 de Enero whatsapp 3.0 Las ventas se logran el 90% con una estrategia comunicacional y el 10% con tecnología. En nuestro webinar podrás conocer todo lo que debes saber sobre WhatsApp, esta poderosa herramienta que todos utilizamos de manera personal y que tiene un potencial increíble para los negocios, en específico, las ventas. Conoceremos las novedosas prácticas que te ofrece la aplicación WhatsApp cómo herramienta para impulsar ventas. Ejes Temáticos: • WhatsApp cómo poderosa herramienta de ventas. • Errores comunes al utilizar WhatsApp cómo herramienta de Marketing. • Atención al cliente como estrategia de fidelización. • Software para envíos masivos. Para mayor información, responder sobre este correo con la palabra Whatsapp + los siguientes datos: NOMBRE: TELÉFONO: EMPRESA: Llamanos al (045) 55 1554 6630 www.Innovalearn.mx ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] dpdk: Limit DPDK memory usage.
Bleep bloop. Greetings Ilya Maximets, I am a robot and I have tried out your patch. Thanks for your contribution. I encountered some error that I wasn't expecting. See the details below. git-am: Failed to merge in the changes. Patch failed at 0001 dpdk: Limit DPDK memory usage. 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
Re: [ovs-dev] [PATCH v4 0/4] dpcls subtable miniflow optimizations
> -Original Message- > From: Aaron Conole [mailto:acon...@redhat.com] > Sent: Monday, January 21, 2019 4:55 PM > To: Ilya Maximets > Cc: Van Haaren, Harry ; ovs-dev@openvswitch.org; > Stokes, Ian > Subject: Re: [ovs-dev] [PATCH v4 0/4] dpcls subtable miniflow optimizations > > Ilya Maximets writes: > > > On 21.01.2019 19:01, Aaron Conole wrote: > >> Harry van Haaren writes: > >> > >>> Hi Folks, > >>> > >>> This patchset is a v4, changes from v3 are a fix to the issue reported > >>> by Ilya (see v3 patchset for details). Note that this patchset enables > >>> the work as presented at OVS Conf last December, particularly this is > >>> the function pointer part: https://www.youtube.com/watch?v=5-MDlpUIOBE > >> > >> Hi Harry, > >> > >> I'm seeing quite a few failures associated with this patch set (see > >> below log for an example): > >> > >>https://api.travis-ci.org/v3/job/482434899/log.txt > > > > The most of failures are because of ukey installation failures: > > > > 2019-01-21T15:06:03.609Z|00267|ofproto_dpif_upcall|WARN|upcall_cb > > failure: ukey installation fails > > > > And also because some packets was missed in stats (probably dropped > because > > of processing issues) > > > >> > >> Seems to be with gcc and the test suite. The clang builds don't seem to > >> be impacted. > > > > We're not running testsuite with clang in Travis, actually, regardless of > > 'TESTSUITE' variable. That is the reason of green clang builds. > > Okay - I'll look at a cooking up a patch (I've already started on one to > enable 'DPDK=1 TESTSUITE=1'). It isn't clear currently why it should be > disabled still (I realize it was for the total build time, but the > travis build is currently over 2 hours... seems better to just > re-enable). Thanks for reporting - I've been testing with "real" traffic and haven't been reproducing issues. I'll focus on these test cases, and get back. Cheers, -H ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] dpdk: Limit DPDK memory usage.
Since 18.05 release, DPDK moved to dynamic memory model in which
hugepages could be allocated on demand. At the same time '--socket-mem'
option was re-defined as a size of pre-allocated memory, i.e. memory
that should be allocated at startup and could not be freed.
So, DPDK with a new memory model could allocate more hugepage memory
than specified in '--socket-mem' or '-m' options.
This change adds new configurable 'other_config:dpdk-socket-limit'
which could be used to limit the ammount of memory DPDK could use.
It uses new DPDK option '--socket-limit'.
Ex.:
ovs-vsctl set Open_vSwitch . other_config:dpdk-socket-limit="1024,1024"
Also, in order to preserve old behaviour, if '--socket-limit' is not
specified, it will be defaulted to the amount of memory specified by
'--socket-mem' option, i.e. OVS will not be able to allocate more.
This is needed, for example, to disallow OVS to allocate more memory
than reserved for it by Nova in OpenStack installations.
Signed-off-by: Ilya Maximets
---
Argument parsing refactoring should be applied first.
Based-on: https://patchwork.ozlabs.org/project/openvswitch/list/?series=87518
Aaron, what do you think about supporting tags like 'Based-on' in ovsrobot ?
For example, patchew in QEMU parses 'Based-on: ' tags.
Maybe we can use patchwork ids or something similar.
NEWS | 3 +++
lib/dpdk.c | 21 +++--
vswitchd/vswitch.xml | 22 ++
3 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/NEWS b/NEWS
index 4985dbaac..a64b9d94d 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,8 @@
Post-v2.11.0
-
+ - DPDK:
+ * New option 'other_config:dpdk-socket-limit' to limit amount of
+ hugepage memory that can be used by DPDK.
v2.11.0 - xx xxx
diff --git a/lib/dpdk.c b/lib/dpdk.c
index 855bcf013..931249451 100644
--- a/lib/dpdk.c
+++ b/lib/dpdk.c
@@ -100,8 +100,9 @@ construct_dpdk_options(const struct smap *ovs_other_config,
struct svec *args)
bool default_enabled;
const char *default_value;
} opts[] = {
-{"dpdk-lcore-mask", "-c", false, NULL},
-{"dpdk-hugepage-dir", "--huge-dir", false, NULL},
+{"dpdk-lcore-mask", "-c", false, NULL},
+{"dpdk-hugepage-dir", "--huge-dir", false, NULL},
+{"dpdk-socket-limit", "--socket-limit", false, NULL},
};
int i;
@@ -318,6 +319,22 @@ dpdk_init__(const struct smap *ovs_other_config)
svec_add(, ovs_get_program_name());
construct_dpdk_args(ovs_other_config, );
+if (!args_contains(, "--legacy-mem")
+&& !args_contains(, "--socket-limit")) {
+const char *arg;
+size_t i;
+
+SVEC_FOR_EACH (i, arg, ) {
+if (!strcmp(arg, "--socket-mem")) {
+break;
+}
+}
+if (i < args.n - 1) {
+svec_add(, "--socket-limit");
+svec_add(, args.names[i + 1]);
+}
+}
+
if (args_contains(, "-c") || args_contains(, "-l")) {
auto_determine = false;
}
diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
index 88edb5d35..68da6f75c 100644
--- a/vswitchd/vswitch.xml
+++ b/vswitchd/vswitch.xml
@@ -333,6 +333,28 @@
+
+
+ Limits the maximum amount of memory that can be used from the
+ hugepage pool, on a per-socket basis.
+
+
+ The specifier is a comma-separated list of memory limits per socket.
+ 0 will disable the limit for a particular socket.
+
+
+ If not specified, OVS will configure limits equal to the amount of
+ preallocated memory specified by or --socket-mem in
+ . If none of the above
+ options specified or --legacy-mem provided in
+ , limits will not be
+ applied.
+ Changing this value requires restarting the daemon.
+
+
+
--
2.17.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Indicadores de compras
Cursos TOP - Webinar Interactivo – Martes 29 de Enero Indicadores de compras para una aministración óptima Medir los indicadores es una tarea fundamental en la administración de un departamento y más si desea hacerse de manera óptima. Además, puede resultar la diferencia para conseguir costos bajos, ofrecer precios más accesibles y enriquecer la relación ganar- ganar con el cliente y ubicarnos en una posición de ventaja frente a nuestros competidores. Diseñaremos estrategias que permitan la optimización de los principales indicadores del departamento de compras. Ejes Temáticos: • Objetivos y definición de indicadores. • Control y calidad. • Indicadores económicos y de precio. • Proveedores y su desempeño. Para mayor información, responder sobre este correo con la palabra compras + los siguientes datos: NOMBRE: TELÉFONO: EMPRESA: Llamanos al (045) 55 1554 6630 www.innovalearn.mx ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 0/2] Use existing data structures while dpdk args construction.
Ilya Maximets writes: > Ilya Maximets (2): > dpdk: Use svec instead of re-inventing. > dpdk: Use dynamic string for socket-mem construction. > > lib/dpdk.c | 230 + > 1 file changed, 71 insertions(+), 159 deletions(-) For the series, Acked-by: Aaron Conole Thanks, Ilya! ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 2/2] dpdk: Use dynamic string for socket-mem construction.
No need to allocate memory and use 'strcat' direcly.
'dynamic-string' could do this for us.
Signed-off-by: Ilya Maximets
---
lib/dpdk.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/lib/dpdk.c b/lib/dpdk.c
index d70884aad..855bcf013 100644
--- a/lib/dpdk.c
+++ b/lib/dpdk.c
@@ -129,23 +129,20 @@ construct_dpdk_options(const struct smap
*ovs_other_config, struct svec *args)
static char *
construct_dpdk_socket_mem(void)
{
-int numa;
const char *def_value = "1024";
-int numa_nodes = ovs_numa_get_n_numas();
+int numa, numa_nodes = ovs_numa_get_n_numas();
+struct ds dpdk_socket_mem = DS_EMPTY_INITIALIZER;
if (numa_nodes == 0 || numa_nodes == OVS_NUMA_UNSPEC) {
numa_nodes = 1;
}
-/* Allocate enough memory for digits, comma-sep and terminator. */
-char *dpdk_socket_mem = xzalloc(numa_nodes * (strlen(def_value) + 1));
-strcat(dpdk_socket_mem, def_value);
+ds_put_cstr(_socket_mem, def_value);
for (numa = 1; numa < numa_nodes; ++numa) {
-strcat(dpdk_socket_mem, ",");
-strcat(dpdk_socket_mem, def_value);
+ds_put_format(_socket_mem, ",%s", def_value);
}
-return dpdk_socket_mem;
+return ds_cstr(_socket_mem);
}
#define MAX_DPDK_EXCL_OPTS 10
--
2.17.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 1/2] dpdk: Use svec instead of re-inventing.
No need to implement dynamic vector to store arguments.
'svec' perfectly covers all the needed functionality.
Signed-off-by: Ilya Maximets
---
lib/dpdk.c | 217 -
1 file changed, 66 insertions(+), 151 deletions(-)
diff --git a/lib/dpdk.c b/lib/dpdk.c
index 0ee3e19c6..d70884aad 100644
--- a/lib/dpdk.c
+++ b/lib/dpdk.c
@@ -38,6 +38,7 @@
#include "openvswitch/vlog.h"
#include "ovs-numa.h"
#include "smap.h"
+#include "svec.h"
#include "vswitch-idl.h"
VLOG_DEFINE_THIS_MODULE(dpdk);
@@ -75,65 +76,23 @@ process_vhost_flags(char *flag, const char *default_val,
int size,
return changed;
}
-static char **
-grow_argv(char ***argv, size_t cur_siz, size_t grow_by)
-{
-return xrealloc(*argv, sizeof(char *) * (cur_siz + grow_by));
-}
-
-static void
-dpdk_option_extend(char ***argv, int argc, const char *option,
- const char *value)
-{
-char **newargv = grow_argv(argv, argc, 2);
-*argv = newargv;
-newargv[argc] = xstrdup(option);
-newargv[argc+1] = xstrdup(value);
-}
-
-static char **
-move_argv(char ***argv, size_t cur_size, char **src_argv, size_t src_argc)
-{
-char **newargv = grow_argv(argv, cur_size, src_argc);
-while (src_argc--) {
-newargv[cur_size+src_argc] = src_argv[src_argc];
-src_argv[src_argc] = NULL;
-}
-return newargv;
-}
-
-static int
-extra_dpdk_args(const char *ovs_extra_config, char ***argv, int argc)
-{
-int ret = argc;
-char *release_tok = xstrdup(ovs_extra_config);
-char *tok, *endptr = NULL;
-
-for (tok = strtok_r(release_tok, " ", ); tok != NULL;
- tok = strtok_r(NULL, " ", )) {
-char **newarg = grow_argv(argv, ret, 1);
-*argv = newarg;
-newarg[ret++] = xstrdup(tok);
-}
-free(release_tok);
-return ret;
-}
-
static bool
-argv_contains(char **argv_haystack, const size_t argc_haystack,
- const char *needle)
+args_contains(const struct svec *args, const char *needle)
{
-for (size_t i = 0; i < argc_haystack; ++i) {
-if (!strcmp(argv_haystack[i], needle))
+const char *arg;
+size_t i;
+
+/* We can't just use 'svec_contains' because args are not sorted. */
+SVEC_FOR_EACH (i, arg, args) {
+if (!strcmp(arg, needle)) {
return true;
+}
}
return false;
}
-static int
-construct_dpdk_options(const struct smap *ovs_other_config,
- char ***argv, const int initial_size,
- char **extra_args, const size_t extra_argc)
+static void
+construct_dpdk_options(const struct smap *ovs_other_config, struct svec *args)
{
struct dpdk_options_map {
const char *ovs_configuration;
@@ -145,28 +104,26 @@ construct_dpdk_options(const struct smap
*ovs_other_config,
{"dpdk-hugepage-dir", "--huge-dir", false, NULL},
};
-int i, ret = initial_size;
+int i;
/*First, construct from the flat-options (non-mutex)*/
for (i = 0; i < ARRAY_SIZE(opts); ++i) {
-const char *lookup = smap_get(ovs_other_config,
- opts[i].ovs_configuration);
-if (!lookup && opts[i].default_enabled) {
-lookup = opts[i].default_value;
+const char *value = smap_get(ovs_other_config,
+ opts[i].ovs_configuration);
+if (!value && opts[i].default_enabled) {
+value = opts[i].default_value;
}
-if (lookup) {
-if (!argv_contains(extra_args, extra_argc, opts[i].dpdk_option)) {
-dpdk_option_extend(argv, ret, opts[i].dpdk_option, lookup);
-ret += 2;
+if (value) {
+if (!args_contains(args, opts[i].dpdk_option)) {
+svec_add(args, opts[i].dpdk_option);
+svec_add(args, value);
} else {
VLOG_WARN("Ignoring database defined option '%s' due to "
- "dpdk_extras config", opts[i].dpdk_option);
+ "dpdk_extra config", opts[i].dpdk_option);
}
}
}
-
-return ret;
}
static char *
@@ -193,12 +150,12 @@ construct_dpdk_socket_mem(void)
#define MAX_DPDK_EXCL_OPTS 10
-static int
+static void
construct_dpdk_mutex_options(const struct smap *ovs_other_config,
- char ***argv, const int initial_size,
- char **extra_args, const size_t extra_argc)
+ struct svec *args)
{
char *default_dpdk_socket_mem = construct_dpdk_socket_mem();
+
struct dpdk_exclusive_options_map {
const char *category;
const char *ovs_dpdk_options[MAX_DPDK_EXCL_OPTS];
@@ -213,7 +170,7 @@ construct_dpdk_mutex_options(const struct smap
*ovs_other_config,
},
};
-int i, ret = initial_size;
+int i;
for (i = 0; i < ARRAY_SIZE(excl_opts); ++i) {
int found_opts = 0,
[ovs-dev] [PATCH 0/2] Use existing data structures while dpdk args construction.
Ilya Maximets (2): dpdk: Use svec instead of re-inventing. dpdk: Use dynamic string for socket-mem construction. lib/dpdk.c | 230 + 1 file changed, 71 insertions(+), 159 deletions(-) -- 2.17.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] seq: Correct example in comment.
On 22.01.2019 4:14, Ben Pfaff wrote:
> It was deceptive for the example to imply that a seq can be declared
> directly, because the API only allows for creating a new one on the heap.
>
> Signed-off-by: Ben Pfaff
> ---
> lib/seq.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Thanks.
Maybe you can additionally fix the C99-style comment here to not use
a bad style inside the example.
Anyway,
Acked-by: Ilya Maximets
> diff --git a/lib/seq.h b/lib/seq.h
> index 221ab9acddc5..92743c1eb4ea 100644
> --- a/lib/seq.h
> +++ b/lib/seq.h
> @@ -77,14 +77,14 @@
> *
> *struct ovs_mutex mutex;
> *struct ovs_list queue OVS_GUARDED_BY(mutex);
> - *struct seq nonempty_seq;
> + *struct seq *nonempty_seq;
> *
> * To add an element to the queue:
> *
> *ovs_mutex_lock();
> *ovs_list_push_back(, ...element...);
> *if (ovs_list_is_singleton()) { // The 'if' test here is
> optional.
> - *seq_change(_seq);
> + *seq_change(nonempty_seq);
> *}
> *ovs_mutex_unlock();
> *
> @@ -92,7 +92,7 @@
> *
> *ovs_mutex_lock();
> *if (ovs_list_is_empty()) {
> - *seq_wait(_seq, seq_read(_seq));
> + *seq_wait(nonempty_seq, seq_read(nonempty_seq));
> *} else {
> *poll_immediate_wake();
> *}
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
