[ovs-dev] Violencia en el trabajo
Implemente un plan de prevención y corrección ante estas situaciones Violencia en el trabajo: Protocolo anti hostigamiento sexual y laboral 15 de Febrero- Mtra. Leticia Tercero Leyzaola - 9am- 6pm En el año 2016 la Secretaría del Trabajo y Previsión Social (STPS) presentó el Protocolo de Actuación Frente a Casos de Violencia Laboral, Hostigamiento y Acoso Sexual, dirigido a todas las empresas de la República Mexicana. Se ha mencionado que las empresas que desarrollan políticas para la prevención y atención de la violencia han tenido impacto positivo en la calidad de vida laboral, clima organizacional, salud de los colaboradores y productividad en los negocios. BENEFICIOS DE ASISTIR: 1. Sabrá cómo dar cumplimiento a la Ley Federal del Trabajo en materia de prevención del acoso laboral, así como proteger a los colaboradores que no sean víctimas de conductas de acoso. 2. Hará conciencia del alcance del acoso y sus efectos negativos en la productividad de la empresa. 3. Creará una cultura empresarial de profundo respeto entre colaboradores. 4. Elaborará un plan de acción viable para aplicarlo en su organización. 5. Aprenderá la forma de legal de resolver esta problemática ¿Requiere la información a la Brevedad? responda este email con la palabra: Violencia + nombre - teléfono - correo. centro telefónico:018002120744 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Manejo Efectivo de cajas de ahorro
Manejo de cajas de ahorro Febrero 27 - webinar Interactivo Objetivo: La implantación del plan de caja o fondo de ahorro en la compañía generalmente tiene como objetivo beneficiar a los trabajadores recibiendo una percepción exenta de impuestos, además de brindarles acceso a financiamiento personal y fomentar la necesidad del ahorro, independientemente del beneficio de la empresa al reflejar el costo fiscal en sus contratos laborales. Temario: -Evolución de los mecanismos de remuneración. - Los salarios fijos, variables y mixtos - Evolución de las remuneraciones exenta para el trabajador. - Nacimiento de los fondos de ahorro en la legislación mexicana. Historial, desarrollo, restricciones. - Esquema vigente en la reforma fiscal sobre la exención del fondo de ahorro y... ¿Perjudica al sector empresarial? - Restricciones que han desalentado el estímulo de la formación de fondos de ahorro. Temario e Inscripciones: Respondiendo por este medio "Cajas"+TELÉFONO + NOMBRE o marcando al: 045 + 5515546630 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 0/5] datapath: enable NSH support in kernel compat mode
On 2/7/2018 10:46 AM, Ben Pfaff wrote: On Fri, Feb 02, 2018 at 10:23:04AM -0800, Gregory Rose wrote: On 1/31/2018 5:53 AM, Yi Yang wrote: v1->v2 - Fix compilation error in linux-3.10.107 This patch series is to backport NSH support patches in Linux net-next tree to OVS in order that it can support NSH in kernel compat mode. Yi Yang (5): datapath: ether: add NSH ethertype datapath: vxlan: factor out VXLAN-GPE next protocol datapath: net: add NSH header structures and helpers datapath: nsh: add GSO support datapath: enable NSH support NEWS | 1 + acinclude.m4 | 1 + datapath/Modules.mk | 4 +- datapath/actions.c| 116 datapath/datapath.c | 4 + datapath/flow.c | 51 datapath/flow.h | 7 + datapath/flow_netlink.c | 343 +- datapath/flow_netlink.h | 5 + datapath/linux/Modules.mk | 2 + datapath/linux/compat/include/linux/if_ether.h| 4 + datapath/linux/compat/include/linux/netdevice.h | 14 + datapath/linux/compat/include/linux/openvswitch.h | 6 +- datapath/linux/compat/include/net/nsh.h | 313 datapath/linux/compat/include/net/tun_proto.h | 49 datapath/linux/compat/include/net/vxlan.h | 6 - datapath/linux/compat/vxlan.c | 32 +- datapath/nsh.c| 142 + 18 files changed, 1063 insertions(+), 37 deletions(-) create mode 100644 datapath/linux/compat/include/net/nsh.h create mode 100644 datapath/linux/compat/include/net/tun_proto.h create mode 100644 datapath/nsh.c Yi, I have finished review of the patches and they look fine to me. As per our offline discussions it doesn't seem as if there is a test framework available for me right now to be able to test the patches but I did make sure there are no regressions in our current test and compile. The patches passed the travis check here: https://travis-ci.org/gvrose8192/ovs-experimental/builds/336662468 I am collaborating with a co-worker here at VMware to document and create an NSH test bed but that won't be done for a while. I'll go ahead and provide my review sign off but for obvious reasons I can't apply a tested by sign off. I think the patches are pretty well vetted both upstream and here and I think they're fine to apply so that we can get started testing. I don't think there will be any negative effect on current features or code stability - no "make check" and "make check-kmod" tests show any regressions It will be up to the maintainers whether this is sufficient to apply your patches. For the series... Reviewed-by: Greg Rose Thanks Yi and Greg, I applied this to master. Should I backport to branch-2.9? We should get Yi's opinion as well but from my perspective I think just applying to master is fine for now. Unless maybe there is some specific request from the community or a partner. It's only just present in the 4.15 kernel release which just came out. I checked with the lexer and it is not present in 4.14. My two cents anyway... Thanks, - Greg ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 0/5] datapath: enable NSH support in kernel compat mode
On Fri, Feb 02, 2018 at 10:23:04AM -0800, Gregory Rose wrote: > On 1/31/2018 5:53 AM, Yi Yang wrote: > >v1->v2 > > - Fix compilation error in linux-3.10.107 > > > >This patch series is to backport NSH support patches in Linux net-next tree > >to OVS in order that it can support NSH in kernel compat mode. > > > >Yi Yang (5): > > datapath: ether: add NSH ethertype > > datapath: vxlan: factor out VXLAN-GPE next protocol > > datapath: net: add NSH header structures and helpers > > datapath: nsh: add GSO support > > datapath: enable NSH support > > > > NEWS | 1 + > > acinclude.m4 | 1 + > > datapath/Modules.mk | 4 +- > > datapath/actions.c| 116 > > datapath/datapath.c | 4 + > > datapath/flow.c | 51 > > datapath/flow.h | 7 + > > datapath/flow_netlink.c | 343 > > +- > > datapath/flow_netlink.h | 5 + > > datapath/linux/Modules.mk | 2 + > > datapath/linux/compat/include/linux/if_ether.h| 4 + > > datapath/linux/compat/include/linux/netdevice.h | 14 + > > datapath/linux/compat/include/linux/openvswitch.h | 6 +- > > datapath/linux/compat/include/net/nsh.h | 313 > > > > datapath/linux/compat/include/net/tun_proto.h | 49 > > datapath/linux/compat/include/net/vxlan.h | 6 - > > datapath/linux/compat/vxlan.c | 32 +- > > datapath/nsh.c| 142 + > > 18 files changed, 1063 insertions(+), 37 deletions(-) > > create mode 100644 datapath/linux/compat/include/net/nsh.h > > create mode 100644 datapath/linux/compat/include/net/tun_proto.h > > create mode 100644 datapath/nsh.c > > > > Yi, > > I have finished review of the patches and they look fine to me. As per our > offline discussions it > doesn't seem as if there is a test framework available for me right now to > be able to test the patches > but I did make sure there are no regressions in our current test and > compile. The patches passed > the travis check here: > > https://travis-ci.org/gvrose8192/ovs-experimental/builds/336662468 > > I am collaborating with a co-worker here at VMware to document and create an > NSH test bed but that won't > be done for a while. > > I'll go ahead and provide my review sign off but for obvious reasons I can't > apply a tested by sign off. > I think the patches are pretty well vetted both upstream and here and I > think they're fine to apply so > that we can get started testing. I don't think there will be any negative > effect on current features or > code stability - no "make check" and "make check-kmod" tests show any > regressions It will be up to > the maintainers whether this is sufficient to apply your patches. > > For the series... > > Reviewed-by: Greg Rose Thanks Yi and Greg, I applied this to master. Should I backport to branch-2.9? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH V3] rhel: Fix support for root user using DPDK
Aaron Conole writes:
> Ben Pfaff writes:
>
>> Well, is it ever useful to be able to drop unneeded capabilities while
>> retaining the same uid/gid? It certainly sounds like a reasonable thing
>> to want to do. I'm reluctant to apply this without at least considering
>> that possibility.
>
> Let me think about it a bit more. When I originally suggested shunting
> the setuid code-path, I didn't consider this case. There could be an
> alternative.
>
> I suggested this in response to the original proposal (add CAP_SYS_ADMIN
> to the list of retained privs). Certainly, I don't want to allow
> CAP_SYS_ADMIN to be retained (after all, with CAP_NET_ADMIN and
> CAP_SYS_ADMIN, there's really not much reason to change uid from root at
> all - for all functional purposes the process will be root).
>
> Maybe there's a way to see that the user will be root from the
> systemd scripts and not pass the "--user=XXX:YYY" option.
Is the following patch a workable solution? If so, I can post it
formally. Marcos, please confirm that this resolves your issue?
---
diff --git a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
index c6d9aa1b8..889740f1a 100644
--- a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
+++ b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
@@ -13,17 +13,18 @@ Restart=on-failure
Environment=HOME=/var/run/openvswitch
EnvironmentFile=/etc/openvswitch/default.conf
EnvironmentFile=-/etc/sysconfig/openvswitch
+EnvironmentFile=-/run/openvswitch/useropts
@begin_dpdk@
-ExecStartPre=-/usr/bin/chown :hugetlbfs /dev/hugepages
+ExecStartPre=-/bin/sh -c '/usr/bin/chown :${OVS_USER_ID##*:} /dev/hugepages'
ExecStartPre=-/usr/bin/chmod 0775 /dev/hugepages
@end_dpdk@
ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \
--no-ovsdb-server --no-monitor --system-id=random \
- --ovs-user=${OVS_USER_ID} \
+ ${OVSUSER} \
start $OPTIONS
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 \
- --ovs-user=${OVS_USER_ID} \
+ ${OVSUSER} \
restart $OPTIONS
TimeoutSec=300
diff --git a/rhel/usr_lib_systemd_system_ovsdb-server.service
b/rhel/usr_lib_systemd_system_ovsdb-server.service
index 234d39355..e05742d87 100644
--- a/rhel/usr_lib_systemd_system_ovsdb-server.service
+++ b/rhel/usr_lib_systemd_system_ovsdb-server.service
@@ -11,13 +11,15 @@ Restart=on-failure
EnvironmentFile=/etc/openvswitch/default.conf
EnvironmentFile=-/etc/sysconfig/openvswitch
ExecStartPre=/usr/bin/chown ${OVS_USER_ID} /var/run/openvswitch
+ExecStartPre=/bin/sh -c 'rm -f /run/openvswitch/useropts; if [
"${OVS_USER_ID/:*/}" != "root" ]; then /usr/bin/echo
"OVSUSER=--ovs-user=${OVS_USER_ID}" > /run/openvswitch/useropts; fi'
+EnvironmentFile=-/run/openvswitch/useropts
ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \
--no-ovs-vswitchd --no-monitor --system-id=random \
- --ovs-user=${OVS_USER_ID} \
+ ${OVSUSER} \
start $OPTIONS
ExecStop=/usr/share/openvswitch/scripts/ovs-ctl --no-ovs-vswitchd stop
ExecReload=/usr/share/openvswitch/scripts/ovs-ctl --no-ovs-vswitchd \
- --ovs-user=${OVS_USER_ID} \
+ ${OVSUSER} \
--no-monitor restart $OPTIONS
RuntimeDirectory=openvswitch
RuntimeDirectoryMode=0755
---
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] porting Open vSwitch to supermicro swithes
On Wed, Feb 07, 2018 at 05:22:44PM +0600, Oleg Matsiyevich wrote: > Dear colleagues, please tell me whether it is possible to porting your > solution Open vSwitch for SDN Switches from Supermicro such as > SSE-X3648S, x86_64 Broadcom Trident2 and SSE-G3648B x86_64 Broadcom > Helix4 ? Probably, but Broadcom policies prohibit making the ports open source, so you will probably have to ask a switch vendor for such a port under NDA. Broadcom recently relaxed its policies, but it's not clear to me yet whether the changes make it possible to have an open source port. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 3/3] expr: Add additional invariant check in test.
On Wed, Feb 07, 2018 at 06:28:05PM +0530, Numan Siddique wrote: > On Tue, Feb 6, 2018 at 11:30 PM, Ben Pfaff wrote: > > > Signed-off-by: Ben Pfaff > > > > Acked-by: Numan Siddique Thank you for the reviews. I applied this series to master. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [RFC] dpif-netlink: don't allocate per port netlink sockets
On Wed, Feb 07, 2018 at 03:47:09PM +0100, Jiri Benc wrote: > On Tue, 23 Jan 2018 09:50:00 -0800, Ben Pfaff wrote: > > Per-port sockets help OVS to improve fairness, so that a single busy > > port can't monopolize all slow-path resources. We can't just throw that > > away. If there's a problem with too many netlink sockets, let's come up > > with a solution, but it can't be to eliminate fairness entirely. > > The main problem with this is the sockets are dedicated to particular > ports. With high number of ports, the number of sockets raises to such > high value that it stops helping performance anyway. There's not much > point of having thousands opened sockets per CPU, we'll not be able to > utilize them anyway. > > Having dedicated sockets for each port is wasteful, especially if one > port is very busy with upcalls and other ports are mostly idle. (And if > many ports are busy with many upcalls, we're in performance troubles > anyway.) It would make sense to share the sockets between the ports. > > I'd like to understand more about the thoughts behind the fairness. Why > should not a single busy port use all slow-path resources in case other > ports are idle? A single busy port should use all slow-path resources when other ports are idle. That is not a fairness problem. A single busy port should not use all slow-path resources when other ports have some traffic. If port p0 sends 100,000 packets per second to the slow path (much more than the slow path can actually process) and port p1 sends 1 packet per second to the slow path, p1 should get service, but it is likely to not get any service at all if all of its packets are lumped in with p0. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] OVS DPDK Mempool revert
Hi all, As discussed on the OVS-DPDK community call, I've manually reverted the per port mempool changes in OVS-DPDK on a branch on my own git hub. This had to be re-introduced manually due to the number of commits and work that had went on top of the per port implementation. For testing people can access it from the link below: https://github.com/istokes/ovs/tree/mempool_revert If we are to revert this in time for OVS 2.9 there is a need for validation among the community to ensure that it does not break any features. I have validated most existing features with VSperf but I'm more interested in ensuring existing user test cases do not break with this revert. There's some clean for the commit message and the formatting also as is. I can submit an RFC once I have completed this but functionally this can be tested now. Thanks Ian ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] question about dp_packet lifetime
> Hi, Hi, Alessandro. > > My name is Alessandro Rosetti, and I'm currently adding netmap support to > ovs, following an approach similar to DPDK. Good to know that someone started to work on this. IMHO, it's a good idea. I also wanted to try to implement this someday, but had no much time. > > I've created a new netdev: netdev_netmap that uses the pmd infrastructure. > The prototype I have seems to work fine (I still need to tune performance, > test optional features, and test more complex topologies.) Cool. Looking forward for your RFC patch-set. > > I have a question about the lifetime of dp_packets. > Is there any guarantee that the dp_packets allocated in a receive callback > (e.g. netdev_netmap_rxq_recv) are consumed by OVS (e.g. dropped, cloned, or > sent to other ports) **before** a subsequent call to the receive callback > (on the same port)? > Or is it possible for dp_packets to be stored somewhere (e.g. in an OVS > internal queue) and live across subsequent invocations of the receive > callback that allocated them? I think that there was never such a guarantee, but recent changes in userspace datapath completely ruined this assumption. I mean output packet batching support. Please refer the following commits for details: 009e003 2017-12-14 | dpif-netdev: Output packet batching. c71ea3c 2018-01-15 | dpif-netdev: Time based output batching. 00adb8d 2018-01-15 | docs: Describe output packet batching in DPDK guide. > > I need to know if this is the case to check that my current prototype is > safe. > I use per-port pre-allocation of dp_packets, for maximum performance. I've > seen that DPDK uses its internal allocator to allocate and deallocate > dp_packets, but netmap does not expose one. > Each packet received with netmap is created as a new type dp_packet: > DPBUF_NETMAP. The data points to a netmap buffer (preallocated by the > kernel). > When I receive data (netdev_netmap_rxq_recv) I reuse the dp_packets, > updating the internal pointer and a couple of additional informations > stored inside the dp_packet. > When I have to send data I use zero copy if dp_packet is DPBUF_NETMAP and > copy if it's not. > > Thanks for the help! > Alessandro. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 11/11] travis: Update kernel test list from kernel.org
Also add package libelf-dev - since 4.14 it's required for making
the source.
Signed-off-by: Greg Rose
---
.travis.yml | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 48acc8e..cfd9b6f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -17,6 +17,7 @@ addons:
- libjemalloc-dev
- libnuma-dev
- python-sphinx
+ - libelf-dev
before_install: ./.travis/${TRAVIS_OS_NAME}-prepare.sh
@@ -26,17 +27,16 @@ sudo: false
env:
- OPTS="--disable-ssl"
- - TESTSUITE=1 KERNEL=3.16.47
+ - TESTSUITE=1 KERNEL=3.16.53
- TESTSUITE=1 OPTS="--enable-shared"
- BUILD_ENV="-m32" OPTS="--disable-ssl"
- - KERNEL=3.16.47 DPDK=1
- - KERNEL=3.16.47 DPDK=1 OPTS="--enable-shared"
- - KERNEL=4.13
- - KERNEL=4.12.11
- - KERNEL=4.9.48
- - KERNEL=4.4.87
- - KERNEL=4.1.43
- - KERNEL=3.10.107
+ - KERNEL=3.16.53 DPDK=1
+ - KERNEL=3.16.53 DPDK=1 OPTS="--enable-shared"
+ - KERNEL=4.14.15
+ - KERNEL=4.9.78
+ - KERNEL=4.4.113
+ - KERNEL=4.1.49
+ - KERNEL=3.10.108
- TESTSUITE=1 LIBS=-ljemalloc
matrix:
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 09/11] Documentation: Update NEWS and faq
Per the Linux 4.14 kernel support. Signed-off-by: Greg Rose --- Documentation/faq/releases.rst | 1 + NEWS | 2 ++ 2 files changed, 3 insertions(+) diff --git a/Documentation/faq/releases.rst b/Documentation/faq/releases.rst index 62a1957..2f03c89 100644 --- a/Documentation/faq/releases.rst +++ b/Documentation/faq/releases.rst @@ -67,6 +67,7 @@ Q: What Linux kernel versions does each Open vSwitch release work with? 2.7.x3.10 to 4.9 2.8.x3.10 to 4.12 2.9.x3.10 to 4.13 +2.10.x 3.10 to 4.14 == Open vSwitch userspace should also work with the Linux kernel module built diff --git a/NEWS b/NEWS index 8c360ba..2e225b0 100644 --- a/NEWS +++ b/NEWS @@ -10,6 +10,8 @@ Post-v2.9.0 * Previous versions gave OpenFlow tables default names of the form "table#". These are not helpful names for the purpose of accepting and displaying table names, so now tables by default have no names. +- Linux kernel 4.14 + * Add support for compiling OVS with the latest Linux 4.14 kernel v2.9.0 - xx xxx -- 1.8.3.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 10/11] acinclude.m4: Enable Linux 4.14
Signed-off-by: Greg Rose --- acinclude.m4 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/acinclude.m4 b/acinclude.m4 index 414b96a..6928db8 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -151,10 +151,10 @@ AC_DEFUN([OVS_CHECK_LINUX], [ AC_MSG_RESULT([$kversion]) if test "$version" -ge 4; then - if test "$version" = 4 && test "$patchlevel" -le 13; then + if test "$version" = 4 && test "$patchlevel" -le 14; then : # Linux 4.x else - AC_ERROR([Linux kernel in $KBUILD is version $kversion, but version newer than 4.13.x is not supported (please refer to the FAQ for advice)]) + AC_ERROR([Linux kernel in $KBUILD is version $kversion, but version newer than 4.14.x is not supported (please refer to the FAQ for advice)]) fi elif test "$version" = 3 && test "$patchlevel" -ge 10; then : # Linux 3.x -- 1.8.3.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 07/11] datapath: meter: fix NULL pointer dereference in ovs_meter_cmd_reply_start
From: "Gustavo A. R. Silva"
Upstream commit:
commit b74912a2fdae9aadd20da502644aa8848c861954
Author: Gustavo A. R. Silva
Date: Tue Nov 14 14:26:16 2017 -0600
openvswitch: meter: fix NULL pointer dereference in ovs_meter_cmd_reply_star
It seems that the intention of the code is to null check the value
returned by function genlmsg_put. But the current code is null
checking the address of the pointer that holds the value returned
by genlmsg_put.
Fix this by properly null checking the value returned by function
genlmsg_put in order to avoid a pontential null pointer dereference.
Addresses-Coverity-ID: 1461561 ("Dereference before null check")
Addresses-Coverity-ID: 1461562 ("Dereference null return value")
Fixes: 96fbc13d7e77 ("openvswitch: Add meter infrastructure")
Signed-off-by: Gustavo A. R. Silva
Signed-off-by: David S. Miller
Cc: Gustavo A. R. Silva
Signed-off-by: Greg Rose
---
datapath/meter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/datapath/meter.c b/datapath/meter.c
index 7b9391d..d36870b 100644
--- a/datapath/meter.c
+++ b/datapath/meter.c
@@ -99,7 +99,7 @@ ovs_meter_cmd_reply_start(struct genl_info *info, u8 cmd,
*ovs_reply_header = genlmsg_put(skb, info->snd_portid,
info->snd_seq,
&dp_meter_genl_family, 0, cmd);
- if (!ovs_reply_header) {
+ if (!*ovs_reply_header) {
nlmsg_free(skb);
return ERR_PTR(-EMSGSIZE);
}
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 08/11] datapath: meter: Use 64-bit arithmetic instead of 32-bit
From: "Gustavo A. R. Silva"
Upstream commit:
commit 5b7789e8fa8f353ad8f2c44de2385cb161b22d32
Author: Gustavo A. R. Silva
Date: Tue Jan 30 22:55:33 2018 -0600
Add suffix LL to constant 1000 in order to give the compiler
complete information about the proper arithmetic to use. Notice
that this constant is used in a context that expects an expression
of type long long int (64 bits, signed).
The expression (band->burst_size + band->rate) * 1000 is currently
being evaluated using 32-bit arithmetic.
Addresses-Coverity-ID: 1461563 ("Unintentional integer overflow")
Signed-off-by: Gustavo A. R. Silva
Signed-off-by: David S. Miller
Signed-off-by: Greg Rose
---
datapath/meter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/datapath/meter.c b/datapath/meter.c
index d36870b..f9e8f12 100644
--- a/datapath/meter.c
+++ b/datapath/meter.c
@@ -498,7 +498,7 @@ bool ovs_meter_execute(struct datapath *dp, struct sk_buff
*skb,
long long int max_bucket_size;
band = &meter->bands[i];
- max_bucket_size = (band->burst_size + band->rate) * 1000;
+ max_bucket_size = (band->burst_size + band->rate) * 1000LL;
band->bucket += delta_ms * band->rate;
if (band->bucket > max_bucket_size)
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 06/11] datapath: Using kfree_rcu() to simplify the code
From: Wei Yongjun
Upstream commit:
commit 6dc14dc40a1d1dafd8491c349b5f3e15aabc4edb
Author: Wei Yongjun
Date: Tue Nov 14 06:27:12 2017 +
openvswitch: Using kfree_rcu() to simplify the code
The callback function of call_rcu() just calls a kfree(), so we
can use kfree_rcu() instead of call_rcu() + callback function.
Signed-off-by: Wei Yongjun
Acked-by: Pravin B Shelar
Signed-off-by: David S. Miller
Cc: Wei Yongjun
Signed-off-by: Greg Rose
---
datapath/meter.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/datapath/meter.c b/datapath/meter.c
index bc940ae..7b9391d 100644
--- a/datapath/meter.c
+++ b/datapath/meter.c
@@ -42,19 +42,12 @@ static const struct nla_policy
band_policy[OVS_BAND_ATTR_MAX + 1] = {
[OVS_BAND_ATTR_STATS] = { .len = sizeof(struct ovs_flow_stats) },
};
-static void rcu_free_ovs_meter_callback(struct rcu_head *rcu)
-{
- struct dp_meter *meter = container_of(rcu, struct dp_meter, rcu);
-
- kfree(meter);
-}
-
static void ovs_meter_free(struct dp_meter *meter)
{
if (!meter)
return;
- call_rcu(&meter->rcu, rcu_free_ovs_meter_callback);
+ kfree_rcu(meter, rcu);
}
static struct hlist_head *meter_hash_bucket(const struct datapath *dp,
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 04/11] datapath: Add meter infrastructure
From: Andy Zhou
Upstream commit:
commit 96fbc13d7e770b542d2d1fcf700d0baadc6e8063
Author: Andy Zhou
Date: Fri Nov 10 12:09:42 2017 -0800
openvswitch: Add meter infrastructure
OVS kernel datapath so far does not support Openflow meter action.
This is the first stab at adding kernel datapath meter support.
This implementation supports only drop band type.
Signed-off-by: Andy Zhou
Signed-off-by: David S. Miller
Added a compat layer fixup for nla_parse.
Added another compat fixup for ktime_get_ns.
Cc: Andy Zhou
Signed-off-by: Greg Rose
---
acinclude.m4| 3 +
datapath/Modules.mk | 6 +-
datapath/datapath.c | 14 +-
datapath/datapath.h | 3 +
datapath/linux/compat/include/net/netlink.h | 9 +
datapath/meter.c| 614
datapath/meter.h| 54 +++
7 files changed, 699 insertions(+), 4 deletions(-)
create mode 100644 datapath/meter.c
create mode 100644 datapath/meter.h
diff --git a/acinclude.m4 b/acinclude.m4
index 8ebbcf8..414b96a 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -807,6 +807,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
OVS_GREP_IFELSE([$KSRC/include/net/net_namespace.h],
[EXPORT_SYMBOL_GPL(peernet2id_alloc)],
[OVS_DEFINE([HAVE_PEERNET2ID_ALLOC])])
+ OVS_GREP_IFELSE([$KSRC/include/linux/timekeeping.h],
+ [ktime_get_ns],
+ [OVS_DEFINE([HAVE_KTIME_GET_NS])])
if cmp -s datapath/linux/kcompat.h.new \
datapath/linux/kcompat.h >/dev/null 2>&1; then
diff --git a/datapath/Modules.mk b/datapath/Modules.mk
index 21f04a0..a9e2880 100644
--- a/datapath/Modules.mk
+++ b/datapath/Modules.mk
@@ -26,7 +26,8 @@ openvswitch_sources = \
flow_table.c \
vport.c \
vport-internal_dev.c \
- vport-netdev.c
+ vport-netdev.c \
+ meter.c
vport_geneve_sources = vport-geneve.c
vport_vxlan_sources = vport-vxlan.c
@@ -43,7 +44,8 @@ openvswitch_headers = \
flow_table.h \
vport.h \
vport-internal_dev.h \
- vport-netdev.h
+ vport-netdev.h \
+ meter.h
dist_sources = $(foreach module,$(dist_modules),$($(module)_sources))
dist_headers = $(foreach module,$(dist_modules),$($(module)_headers))
diff --git a/datapath/datapath.c b/datapath/datapath.c
index 6d9330d..e90177c 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -57,6 +57,7 @@
#include "flow.h"
#include "flow_table.h"
#include "flow_netlink.h"
+#include "meter.h"
#include "gso.h"
#include "vport-internal_dev.h"
#include "vport-netdev.h"
@@ -177,6 +178,7 @@ static void destroy_dp_rcu(struct rcu_head *rcu)
ovs_flow_tbl_destroy(&dp->table);
free_percpu(dp->stats_percpu);
kfree(dp->ports);
+ ovs_meters_exit(dp);
kfree(dp);
}
@@ -1601,6 +1603,10 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct
genl_info *info)
for (i = 0; i < DP_VPORT_HASH_BUCKETS; i++)
INIT_HLIST_HEAD(&dp->ports[i]);
+ err = ovs_meters_init(dp);
+ if (err)
+ goto err_destroy_ports_array;
+
/* Set up our datapath device. */
parms.name = nla_data(a[OVS_DP_ATTR_NAME]);
parms.type = OVS_VPORT_TYPE_INTERNAL;
@@ -1629,7 +1635,7 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct
genl_info *info)
ovs_dp_reset_user_features(skb, info);
}
- goto err_destroy_ports_array;
+ goto err_destroy_meters;
}
err = ovs_dp_cmd_fill_info(dp, reply, info->snd_portid,
@@ -1644,8 +1650,10 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct
genl_info *info)
ovs_notify(&dp_datapath_genl_family, &ovs_dp_datapath_multicast_group,
reply, info);
return 0;
-err_destroy_ports_array:
+err_destroy_meters:
ovs_unlock();
+ ovs_meters_exit(dp);
+err_destroy_ports_array:
kfree(dp->ports);
err_destroy_percpu:
free_percpu(dp->stats_percpu);
@@ -2295,6 +2303,7 @@ static struct genl_family *dp_genl_families[] = {
&dp_vport_genl_family,
&dp_flow_genl_family,
&dp_packet_genl_family,
+ &dp_meter_genl_family,
};
static void dp_unregister_genl(int n_families)
@@ -2488,3 +2497,4 @@ MODULE_ALIAS_GENL_FAMILY(OVS_DATAPATH_FAMILY);
MODULE_ALIAS_GENL_FAMILY(OVS_VPORT_FAMILY);
MODULE_ALIAS_GENL_FAMILY(OVS_FLOW_FAMILY);
MODULE_ALIAS_GENL_FAMILY(OVS_PACKET_FAMILY);
+MODULE_ALIAS_GENL_FAMILY(OVS_METER_FAMILY);
diff --git a/datapath/datapath.h b/datapath/datapath.h
index 7481d6d..93c9ed5 100644
--- a/datapath/datapath.h
+++ b/datapath/datapath.h
@@ -93,6 +93,9 @@ struct datapath {
u32 user_features;
u32 max_headroom;
+
+ /* Switch meters. */
+ struct hlist_head *meters;
};
/**
diff --git a/d
[ovs-dev] [PATCH v2 05/11] datapath: Fix return value check in ovs_meter_cmd_features()
From: Wei Yongjun
Upstream commit:
commit 8a860c2bcc84a8e4fbcabb928cd97e4c51b17d93
Author: Wei Yongjun
Date: Tue Nov 14 06:20:16 2017 +
openvswitch: Fix return value check in ovs_meter_cmd_features()
In case of error, the function ovs_meter_cmd_reply_start() returns
ERR_PTR() not NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Fixes: 96fbc13d7e77 ("openvswitch: Add meter infrastructure")
Signed-off-by: Wei Yongjun
Acked-by: Pravin B Shelar
Signed-off-by: David S. Miller
Cc: Wei Yongjun
Signed-off-by: Greg Rose
---
datapath/meter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/datapath/meter.c b/datapath/meter.c
index 1ab965d..bc940ae 100644
--- a/datapath/meter.c
+++ b/datapath/meter.c
@@ -166,7 +166,7 @@ static int ovs_meter_cmd_features(struct sk_buff *skb,
struct genl_info *info)
reply = ovs_meter_cmd_reply_start(info, OVS_METER_CMD_FEATURES,
&ovs_reply_header);
- if (!reply)
+ if (IS_ERR(reply))
return PTR_ERR(reply);
if (nla_put_u32(reply, OVS_METER_ATTR_MAX_METERS, U32_MAX) ||
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 03/11] datapath: Add meter netlink definitions
From: Andy Zhou
Upstream commit:
commit 5794040647de4011598a6d005fdad95d24fd385b
Author: Andy Zhou
Date: Fri Nov 10 12:09:40 2017 -0800
openvswitch: Add meter netlink definitions
Meter has its own netlink family. Define netlink messages and attributes
for communicating with the user space programs.
Signed-off-by: Andy Zhou
Signed-off-by: David S. Miller
Cc: Andy Zhou
Signed-off-by: Greg Rose
---
datapath/linux/compat/include/linux/openvswitch.h | 51 +++
1 file changed, 51 insertions(+)
diff --git a/datapath/linux/compat/include/linux/openvswitch.h
b/datapath/linux/compat/include/linux/openvswitch.h
index 6081a29..164f57d 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -945,4 +945,55 @@ enum ovs_action_attr {
#define OVS_ACTION_ATTR_MAX (__OVS_ACTION_ATTR_MAX - 1)
+/* Meters. */
+#define OVS_METER_FAMILY "ovs_meter"
+#define OVS_METER_MCGROUP "ovs_meter"
+#define OVS_METER_VERSION 0x1
+
+enum ovs_meter_cmd {
+ OVS_METER_CMD_UNSPEC,
+ OVS_METER_CMD_FEATURES, /* Get features supported by the datapath. */
+ OVS_METER_CMD_SET, /* Add or modify a meter. */
+ OVS_METER_CMD_DEL, /* Delete a meter. */
+ OVS_METER_CMD_GET /* Get meter stats. */
+};
+
+enum ovs_meter_attr {
+ OVS_METER_ATTR_UNSPEC,
+ OVS_METER_ATTR_ID, /* u32 meter ID within datapath. */
+ OVS_METER_ATTR_KBPS,/* No argument. If set, units in kilobits
+* per second. Otherwise, units in
+* packets per second.
+*/
+ OVS_METER_ATTR_STATS, /* struct ovs_flow_stats for the meter. */
+ OVS_METER_ATTR_BANDS, /* Nested attributes for meter bands. */
+ OVS_METER_ATTR_USED,/* u64 msecs last used in monotonic time. */
+ OVS_METER_ATTR_CLEAR, /* Flag to clear stats, used. */
+ OVS_METER_ATTR_MAX_METERS, /* u32 number of meters supported. */
+ OVS_METER_ATTR_MAX_BANDS, /* u32 max number of bands per meter. */
+ OVS_METER_ATTR_PAD,
+ __OVS_METER_ATTR_MAX
+};
+
+#define OVS_METER_ATTR_MAX (__OVS_METER_ATTR_MAX - 1)
+
+enum ovs_band_attr {
+ OVS_BAND_ATTR_UNSPEC,
+ OVS_BAND_ATTR_TYPE, /* u32 OVS_METER_BAND_TYPE_* constant. */
+ OVS_BAND_ATTR_RATE, /* u32 band rate in meter units (see above). */
+ OVS_BAND_ATTR_BURST,/* u32 burst size in meter units. */
+ OVS_BAND_ATTR_STATS,/* struct ovs_flow_stats for the band. */
+ __OVS_BAND_ATTR_MAX
+};
+
+#define OVS_BAND_ATTR_MAX (__OVS_BAND_ATTR_MAX - 1)
+
+enum ovs_meter_band_type {
+ OVS_METER_BAND_TYPE_UNSPEC,
+ OVS_METER_BAND_TYPE_DROP, /* Drop exceeding packets. */
+ __OVS_METER_BAND_TYPE_MAX
+};
+
+#define OVS_METER_BAND_TYPE_MAX (__OVS_METER_BAND_TYPE_MAX - 1)
+
#endif /* _LINUX_OPENVSWITCH_H */
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 02/11] datapath: reliable interface indentification in port dumps
From: Jiri Benc
Upstream commit:
commit 9354d452034273a50a4fd703bea31e5d6b1fc20b
Author: Jiri Benc
Date: Thu Nov 2 17:04:37 2017 -0200
openvswitch: reliable interface indentification in port dumps
This patch allows reliable identification of netdevice interfaces connected
to openvswitch bridges. In particular, user space queries the netdev
interfaces belonging to the ports for statistics, up/down state, etc.
Datapath dump needs to provide enough information for the user space to be
able to do that.
Currently, only interface names are returned. This is not sufficient, as
openvswitch allows its ports to be in different name spaces and the
interface name is valid only in its name space. What is needed and generally
used in other netlink APIs, is the pair ifindex+netnsid.
The solution is addition of the ifindex+netnsid pair (or only ifindex if in
the same name space) to vport get/dump operation.
On request side, ideally the ifindex+netnsid pair could be used to
get/set/del the corresponding vport. This is not implemented by this patch
and can be added later if needed.
Signed-off-by: Jiri Benc
Signed-off-by: David S. Miller
Added compat fixup for peernet2id.
Cc: Jiri Benc
Signed-off-by: Greg Rose
---
acinclude.m4 | 3 ++
datapath/datapath.c | 49 +--
datapath/datapath.h | 4 +-
datapath/dp_notify.c | 3 +-
datapath/linux/compat/include/linux/openvswitch.h | 2 +
5 files changed, 45 insertions(+), 16 deletions(-)
diff --git a/acinclude.m4 b/acinclude.m4
index 6d440f8..8ebbcf8 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -804,6 +804,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
OVS_GREP_IFELSE([$KSRC/include/linux/timekeeping.h],
[ktime_get_ts64],
[OVS_DEFINE([HAVE_KTIME_GET_TS64])])
+ OVS_GREP_IFELSE([$KSRC/include/net/net_namespace.h],
+ [EXPORT_SYMBOL_GPL(peernet2id_alloc)],
+ [OVS_DEFINE([HAVE_PEERNET2ID_ALLOC])])
if cmp -s datapath/linux/kcompat.h.new \
datapath/linux/kcompat.h >/dev/null 2>&1; then
diff --git a/datapath/datapath.c b/datapath/datapath.c
index 6a63a9c..6d9330d 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -1847,7 +1847,8 @@ static struct genl_family dp_datapath_genl_family
__ro_after_init = {
/* Called with ovs_mutex or RCU read lock. */
static int ovs_vport_cmd_fill_info(struct vport *vport, struct sk_buff *skb,
- u32 portid, u32 seq, u32 flags, u8 cmd)
+ struct net *net, u32 portid, u32 seq,
+ u32 flags, u8 cmd)
{
struct ovs_header *ovs_header;
struct ovs_vport_stats vport_stats;
@@ -1863,9 +1864,19 @@ static int ovs_vport_cmd_fill_info(struct vport *vport,
struct sk_buff *skb,
if (nla_put_u32(skb, OVS_VPORT_ATTR_PORT_NO, vport->port_no) ||
nla_put_u32(skb, OVS_VPORT_ATTR_TYPE, vport->ops->type) ||
nla_put_string(skb, OVS_VPORT_ATTR_NAME,
- ovs_vport_name(vport)))
+ ovs_vport_name(vport)) ||
+ nla_put_u32(skb, OVS_VPORT_ATTR_IFINDEX, vport->dev->ifindex))
goto nla_put_failure;
+#ifdef HAVE_PEERNET2ID_ALLOC
+ if (!net_eq(net, dev_net(vport->dev))) {
+ int id = peernet2id_alloc(net, dev_net(vport->dev));
+
+ if (nla_put_s32(skb, OVS_VPORT_ATTR_NETNSID, id))
+ goto nla_put_failure;
+ }
+
+#endif
ovs_vport_get_stats(vport, &vport_stats);
if (nla_put_64bit(skb, OVS_VPORT_ATTR_STATS,
sizeof(struct ovs_vport_stats), &vport_stats,
@@ -1895,8 +1906,8 @@ static struct sk_buff *ovs_vport_cmd_alloc_info(void)
}
/* Called with ovs_mutex, only via ovs_dp_notify_wq(). */
-struct sk_buff *ovs_vport_cmd_build_info(struct vport *vport, u32 portid,
-u32 seq, u8 cmd)
+struct sk_buff *ovs_vport_cmd_build_info(struct vport *vport, struct net *net,
+u32 portid, u32 seq, u8 cmd)
{
struct sk_buff *skb;
int retval;
@@ -1905,7 +1916,7 @@ struct sk_buff *ovs_vport_cmd_build_info(struct vport
*vport, u32 portid,
if (!skb)
return ERR_PTR(-ENOMEM);
- retval = ovs_vport_cmd_fill_info(vport, skb, portid, seq, 0, cmd);
+ retval = ovs_vport_cmd_fill_info(vport, skb, net, portid, seq, 0, cmd);
BUG_ON(retval < 0);
return skb;
@@ -1919,6 +1930,8 @@ static struct vport *lookup_vport(struct net *net,
struct datapath *dp;
struct vport *vport;
+ if (a[OVS_VPORT_ATTR_IFINDEX])
+ return ERR_PTR(-EOPNOTSUPP);
if (a[OVS_VPORT_ATTR_NAME]) {
[ovs-dev] [PATCH v2 01/11] datapath: export get_dp() API
From: Andy Zhou
Upstream commit:
commit 9602c01e57f7b868d748c2ba2aef0efa64b71ffc
Author: Andy Zhou
Date: Fri Nov 10 12:09:41 2017 -0800
openvswitch: export get_dp() API.
Later patches will invoke get_dp() outside of datapath.c. Export it.
Signed-off-by: Andy Zhou
Signed-off-by: David S. Miller
Cc: Andy Zhou
Signed-off-by: Greg Rose
---
datapath/datapath.c | 29 -
datapath/datapath.h | 31 +++
2 files changed, 31 insertions(+), 29 deletions(-)
diff --git a/datapath/datapath.c b/datapath/datapath.c
index 6ee507a..6a63a9c 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -145,35 +145,6 @@ static int queue_userspace_packet(struct datapath *dp,
struct sk_buff *,
const struct dp_upcall_info *,
uint32_t cutlen);
-/* Must be called with rcu_read_lock. */
-static struct datapath *get_dp_rcu(struct net *net, int dp_ifindex)
-{
- struct net_device *dev = dev_get_by_index_rcu(net, dp_ifindex);
-
- if (dev) {
- struct vport *vport = ovs_internal_dev_get_vport(dev);
- if (vport)
- return vport->dp;
- }
-
- return NULL;
-}
-
-/* The caller must hold either ovs_mutex or rcu_read_lock to keep the
- * returned dp pointer valid.
- */
-static inline struct datapath *get_dp(struct net *net, int dp_ifindex)
-{
- struct datapath *dp;
-
- WARN_ON_ONCE(!rcu_read_lock_held() && !lockdep_ovsl_is_held());
- rcu_read_lock();
- dp = get_dp_rcu(net, dp_ifindex);
- rcu_read_unlock();
-
- return dp;
-}
-
/* Must be called with rcu_read_lock or ovs_mutex. */
const char *ovs_dp_name(const struct datapath *dp)
{
diff --git a/datapath/datapath.h b/datapath/datapath.h
index 70ad0ac..036f521 100644
--- a/datapath/datapath.h
+++ b/datapath/datapath.h
@@ -31,6 +31,7 @@
#include "compat.h"
#include "flow.h"
#include "flow_table.h"
+#include "vport-internal_dev.h"
#define DP_MAX_PORTS USHRT_MAX
#define DP_VPORT_HASH_BUCKETS 1024
@@ -197,6 +198,36 @@ static inline struct vport *ovs_vport_ovsl(const struct
datapath *dp, int port_n
return ovs_lookup_vport(dp, port_no);
}
+/* Must be called with rcu_read_lock. */
+static inline struct datapath *get_dp_rcu(struct net *net, int dp_ifindex)
+{
+ struct net_device *dev = dev_get_by_index_rcu(net, dp_ifindex);
+
+ if (dev) {
+ struct vport *vport = ovs_internal_dev_get_vport(dev);
+
+ if (vport)
+ return vport->dp;
+ }
+
+ return NULL;
+}
+
+/* The caller must hold either ovs_mutex or rcu_read_lock to keep the
+ * returned dp pointer valid.
+ */
+static inline struct datapath *get_dp(struct net *net, int dp_ifindex)
+{
+ struct datapath *dp;
+
+ WARN_ON_ONCE(!rcu_read_lock_held() && !lockdep_ovsl_is_held());
+ rcu_read_lock();
+ dp = get_dp_rcu(net, dp_ifindex);
+ rcu_read_unlock();
+
+ return dp;
+}
+
extern struct notifier_block ovs_dp_device_notifier;
extern struct genl_family dp_vport_genl_family;
extern struct genl_multicast_group ovs_dp_vport_multicast_group;
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 00/11] Add upstream Linux 4.14 kernel support
This patch set includes new features from upstream Linux kernel 4.14 as well as some additional bug fixes specific to the new feature. It also updates the travis build kernel list and makes a few other small changes so OVS can compile on Linux 4.14 kernels. This patch set is dependent on the first 10 patches posted here: https://mail.openvswitch.org/pipermail/ovs-dev/2018-February/344253.html V2 of this patch set addresses some suggested changes and also fixes up the .travis.yml file to include libelf-dev as a required package. Andy Zhou (3): datapath: export get_dp() API datapath: Add meter netlink definitions datapath: Add meter infrastructure Greg Rose (3): Documentation: Update NEWS and faq acinclude.m4: Enable Linux 4.14 travis: Update kernel test list from kernel.org Gustavo A. R. Silva (2): datapath: meter: fix NULL pointer dereference in ovs_meter_cmd_reply_start datapath: meter: Use 64-bit arithmetic instead of 32-bit Jiri Benc (1): datapath: reliable interface indentification in port dumps Wei Yongjun (2): datapath: Fix return value check in ovs_meter_cmd_features() datapath: Using kfree_rcu() to simplify the code .travis.yml | 18 +- Documentation/faq/releases.rst| 1 + NEWS | 2 + acinclude.m4 | 10 +- datapath/Modules.mk | 6 +- datapath/datapath.c | 92 ++-- datapath/datapath.h | 38 +- datapath/dp_notify.c | 3 +- datapath/linux/compat/include/linux/openvswitch.h | 53 ++ datapath/linux/compat/include/net/netlink.h | 9 + datapath/meter.c | 607 ++ datapath/meter.h | 54 ++ 12 files changed, 833 insertions(+), 60 deletions(-) create mode 100644 datapath/meter.c create mode 100644 datapath/meter.h -- 1.8.3.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH V2 10/10] datapath: use ktime_get_ts64() instead of ktime_get_ts()
From: Arnd Bergmann
Upstream commit:
commit 311af51dcb5629f04976a8e451673f77e3301041
Author: Arnd Bergmann
Date: Mon Nov 27 12:41:38 2017 +0100
openvswitch: use ktime_get_ts64() instead of ktime_get_ts()
timespec is deprecated because of the y2038 overflow, so let's convert
this one to ktime_get_ts64(). The code is already safe even on 32-bit
architectures, since it uses monotonic times. On 64-bit architectures,
nothing changes, while on 32-bit architectures this avoids one
type conversion.
Signed-off-by: Arnd Bergmann
Signed-off-by: David S. Miller
Additional compatability check for ktime_get_ts64() exists or not.
If not, then just continue using ktime_get_ts(). I added a new
compatability header file "timekeeping.h".
Cc: Arnd Bergmann
Signed-off-by: Greg Rose
---
acinclude.m4 | 3 +++
datapath/flow.c | 7 ---
datapath/linux/Modules.mk | 1 +
datapath/linux/compat/include/linux/timekeeping.h | 11 +++
4 files changed, 19 insertions(+), 3 deletions(-)
create mode 100644 datapath/linux/compat/include/linux/timekeeping.h
diff --git a/acinclude.m4 b/acinclude.m4
index b8ac7db..6d440f8 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -801,6 +801,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
OVS_GREP_IFELSE([$KSRC/include/linux/compiler_types.h],
[__LINUX_COMPILER_TYPES_H],
[OVS_DEFINE([HAVE_LINUX_COMPILER_TYPES_H])])
+ OVS_GREP_IFELSE([$KSRC/include/linux/timekeeping.h],
+ [ktime_get_ts64],
+ [OVS_DEFINE([HAVE_KTIME_GET_TS64])])
if cmp -s datapath/linux/kcompat.h.new \
datapath/linux/kcompat.h >/dev/null 2>&1; then
diff --git a/datapath/flow.c b/datapath/flow.c
index 5da7e3e..1684762 100644
--- a/datapath/flow.c
+++ b/datapath/flow.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -54,12 +55,12 @@
u64 ovs_flow_used_time(unsigned long flow_jiffies)
{
- struct timespec cur_ts;
+ struct timespec64 cur_ts;
u64 cur_ms, idle_ms;
- ktime_get_ts(&cur_ts);
+ ktime_get_ts64(&cur_ts);
idle_ms = jiffies_to_msecs(jiffies - flow_jiffies);
- cur_ms = (u64)cur_ts.tv_sec * MSEC_PER_SEC +
+ cur_ms = (u64)(u32)cur_ts.tv_sec * MSEC_PER_SEC +
cur_ts.tv_nsec / NSEC_PER_MSEC;
return cur_ms - idle_ms;
diff --git a/datapath/linux/Modules.mk b/datapath/linux/Modules.mk
index eec9f23..0fc4132 100644
--- a/datapath/linux/Modules.mk
+++ b/datapath/linux/Modules.mk
@@ -64,6 +64,7 @@ openvswitch_headers += \
linux/compat/include/linux/u64_stats_sync.h \
linux/compat/include/linux/udp.h \
linux/compat/include/linux/workqueue.h \
+ linux/compat/include/linux/timekeeping.h \
linux/compat/include/net/checksum.h \
linux/compat/include/net/dst.h \
linux/compat/include/net/dst_cache.h \
diff --git a/datapath/linux/compat/include/linux/timekeeping.h
b/datapath/linux/compat/include/linux/timekeeping.h
new file mode 100644
index 000..3a3b183
--- /dev/null
+++ b/datapath/linux/compat/include/linux/timekeeping.h
@@ -0,0 +1,11 @@
+#ifndef _LINUX_TIMEKEEPING_WRAPPER_H
+#define _LINUX_TIMEKEEPING_WRAPPER_H
+
+#ifndef HAVE_KTIME_GET_TS64
+#define ktime_get_ts64 ktime_get_ts
+#define timespec64 timespec
+#else
+#include_next
+#endif
+
+#endif
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH V2 09/10] datapath: fix the incorrect flow action alloc size
From: zhangliping
Upstream commit:
commit 67c8d22a73128ff910e2287567132530abcf5b71
Author: zhangliping
Date: Sat Nov 25 22:02:12 2017 +0800
openvswitch: fix the incorrect flow action alloc size
If we want to add a datapath flow, which has more than 500 vxlan outputs'
action, we will get the following error reports:
openvswitch: netlink: Flow action size 32832 bytes exceeds max
openvswitch: netlink: Flow action size 32832 bytes exceeds max
openvswitch: netlink: Actions may not be safe on all matching packets
... ...
It seems that we can simply enlarge the MAX_ACTIONS_BUFSIZE to fix it, but
this is not the root cause. For example, for a vxlan output action, we need
about 60 bytes for the nlattr, but after it is converted to the flow
action, it only occupies 24 bytes. This means that we can still support
more than 1000 vxlan output actions for a single datapath flow under the
the current 32k max limitation.
So even if the nla_len(attr) is larger than MAX_ACTIONS_BUFSIZE, we
shouldn't report EINVAL and keep it move on, as the judgement can be
done by the reserve_sfa_size.
Signed-off-by: zhangliping
Acked-by: Pravin B Shelar
Signed-off-by: David S. Miller
Cc: zhangliping
Signed-off-by: Greg Rose
---
datapath/flow_netlink.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/datapath/flow_netlink.c b/datapath/flow_netlink.c
index 303337c..80c57bd 100644
--- a/datapath/flow_netlink.c
+++ b/datapath/flow_netlink.c
@@ -1909,14 +1909,11 @@ int ovs_nla_put_mask(const struct sw_flow *flow, struct
sk_buff *skb)
#define MAX_ACTIONS_BUFSIZE(32 * 1024)
#endif
-static struct sw_flow_actions *nla_alloc_flow_actions(int size, bool log)
+static struct sw_flow_actions *nla_alloc_flow_actions(int size)
{
struct sw_flow_actions *sfa;
- if (size > MAX_ACTIONS_BUFSIZE) {
- OVS_NLERR(log, "Flow action size %u bytes exceeds max", size);
- return ERR_PTR(-EINVAL);
- }
+ WARN_ON_ONCE(size > MAX_ACTIONS_BUFSIZE);
sfa = kmalloc(sizeof(*sfa) + size, GFP_KERNEL);
if (!sfa)
@@ -1989,12 +1986,15 @@ static struct nlattr *reserve_sfa_size(struct
sw_flow_actions **sfa,
new_acts_size = ksize(*sfa) * 2;
if (new_acts_size > MAX_ACTIONS_BUFSIZE) {
- if ((MAX_ACTIONS_BUFSIZE - next_offset) < req_size)
+ if ((MAX_ACTIONS_BUFSIZE - next_offset) < req_size) {
+ OVS_NLERR(log, "Flow action size exceeds max %u",
+ MAX_ACTIONS_BUFSIZE);
return ERR_PTR(-EMSGSIZE);
+ }
new_acts_size = MAX_ACTIONS_BUFSIZE;
}
- acts = nla_alloc_flow_actions(new_acts_size, log);
+ acts = nla_alloc_flow_actions(new_acts_size);
if (IS_ERR(acts))
return (void *)acts;
@@ -2673,7 +2673,7 @@ int ovs_nla_copy_actions(struct net *net, const struct
nlattr *attr,
{
int err;
- *sfa = nla_alloc_flow_actions(nla_len(attr), log);
+ *sfa = nla_alloc_flow_actions(min(nla_len(attr), MAX_ACTIONS_BUFSIZE));
if (IS_ERR(*sfa))
return PTR_ERR(*sfa);
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH V2 08/10] datapath: fix data type in queue_gso_packets
From: "Gustavo A. R. Silva"
Upstream commit:
commit 2734166e89639c973c6e125ac8bcfc2d9db72b70
Author: Gustavo A. R. Silva
Date: Sat Nov 25 13:14:40 2017 -0600
net: openvswitch: datapath: fix data type in queue_gso_packets
gso_type is being used in binary AND operations together with SKB_GSO_UDP.
The issue is that variable gso_type is of type unsigned short and
SKB_GSO_UDP expands to more than 16 bits:
SKB_GSO_UDP = 1 << 16
this makes any binary AND operation between gso_type and SKB_GSO_UDP to
be always zero, hence making some code unreachable and likely causing
undesired behavior.
Fix this by changing the data type of variable gso_type to unsigned int.
Addresses-Coverity-ID: 1462223
Fixes: 0c19f846d582 ("net: accept UFO datagrams from tuntap and packet")
Signed-off-by: Gustavo A. R. Silva
Acked-by: Willem de Bruijn
Signed-off-by: David S. Miller
While backporting this I found another couple of instances of the
same issue so I fixed them up as well.
Cc: Gustavo A. R. Silva
Signed-off-by: Greg Rose
---
datapath/datapath.c | 2 +-
datapath/linux/compat/stt.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/datapath/datapath.c b/datapath/datapath.c
index 38a453b..6ee507a 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -340,7 +340,7 @@ static int queue_gso_packets(struct datapath *dp, struct
sk_buff *skb,
uint32_t cutlen)
{
#ifdef HAVE_SKB_GSO_UDP
- unsigned short gso_type = skb_shinfo(skb)->gso_type;
+ unsigned int gso_type = skb_shinfo(skb)->gso_type;
struct sw_flow_key later_key;
#endif
struct sk_buff *segs, *nskb;
diff --git a/datapath/linux/compat/stt.c b/datapath/linux/compat/stt.c
index 66a97f2..2189476 100644
--- a/datapath/linux/compat/stt.c
+++ b/datapath/linux/compat/stt.c
@@ -1315,7 +1315,7 @@ static bool validate_checksum(struct sk_buff *skb)
static bool set_offloads(struct sk_buff *skb)
{
struct stthdr *stth = stt_hdr(skb);
- unsigned short gso_type = 0;
+ unsigned int gso_type = 0;
int l3_header_size;
int l4_header_size;
u16 csum_offset;
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH V2 07/10] datapath: Fix an error handling path in 'ovs_nla_init_match_and_action()
From: Christophe JAILLET
Upstream commit:
commit 5829e62ac17a40ab08c1b905565604a4b5fa7af6
Author: Christophe JAILLET
Date: Mon Sep 11 21:56:20 2017 +0200
openvswitch: Fix an error handling path in 'ovs_nla_init_match_and_action()'
All other error handling paths in this function go through the 'error'
label. This one should do the same.
Fixes: 9cc9a5cb176c ("datapath: Avoid using stack larger than 1024.")
Signed-off-by: Christophe JAILLET
Acked-by: Pravin B Shelar
Signed-off-by: David S. Miller
Cc: Christophe JAILLET
Fixes: 850c2a4d1a ("datapath: Avoid using stack larger than 1024.")
Signed-off-by: Greg Rose
---
datapath/datapath.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/datapath/datapath.c b/datapath/datapath.c
index a3fdd8f..38a453b 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -1139,7 +1139,8 @@ static int ovs_nla_init_match_and_action(struct net *net,
if (!a[OVS_FLOW_ATTR_KEY]) {
OVS_NLERR(log,
"Flow key attribute not present in set
flow.");
- return -EINVAL;
+ error = -EINVAL;
+ goto error;
}
*acts = get_flow_actions(net, a[OVS_FLOW_ATTR_ACTIONS], key,
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH V2 06/10] compat: Fix compiler headers
Since Linux kernel upstream commit d15155824c50
("linux/compiler.h: Split into compiler.h and compiler_types.h") this
error check for the gcc compiler header is no longer valid. Remove
so that openvswitch builds for linux kernels 4.14.8 and since.
Signed-off-by: Greg Rose
---
acinclude.m4 | 3 +++
datapath/linux/compat/include/linux/compiler-gcc.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/acinclude.m4 b/acinclude.m4
index 768c20c..b8ac7db 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -798,6 +798,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
OVS_FIND_PARAM_IFELSE([$KSRC/include/linux/netdevice.h],
[netdev_master_upper_dev_link], [extack],
[OVS_DEFINE([HAVE_UPPER_DEV_LINK_EXTACK])])
+ OVS_GREP_IFELSE([$KSRC/include/linux/compiler_types.h],
+ [__LINUX_COMPILER_TYPES_H],
+ [OVS_DEFINE([HAVE_LINUX_COMPILER_TYPES_H])])
if cmp -s datapath/linux/kcompat.h.new \
datapath/linux/kcompat.h >/dev/null 2>&1; then
diff --git a/datapath/linux/compat/include/linux/compiler-gcc.h
b/datapath/linux/compat/include/linux/compiler-gcc.h
index bf057f7..bfcd531 100644
--- a/datapath/linux/compat/include/linux/compiler-gcc.h
+++ b/datapath/linux/compat/include/linux/compiler-gcc.h
@@ -1,6 +1,8 @@
#ifndef __LINUX_COMPILER_H
+#ifndef HAVE_LINUX_COMPILER_TYPES_H
#error "Please don't include directly, include
instead."
#endif
+#endif
#include_next
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH V2 05/10] datapath: Fix SKB_GSO_UDP usage
Using SKB_GSO_UDP breaks the compilation on Linux 4.14. Check for
the HAVE_SKB_GSO_UDP compiler #define.
Signed-off-by: Greg Rose
---
datapath/datapath.c | 9 ++---
datapath/linux/compat/stt.c | 11 ++-
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/datapath/datapath.c b/datapath/datapath.c
index 1780819..a3fdd8f 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -339,8 +339,10 @@ static int queue_gso_packets(struct datapath *dp, struct
sk_buff *skb,
const struct dp_upcall_info *upcall_info,
uint32_t cutlen)
{
+#ifdef HAVE_SKB_GSO_UDP
unsigned short gso_type = skb_shinfo(skb)->gso_type;
struct sw_flow_key later_key;
+#endif
struct sk_buff *segs, *nskb;
struct ovs_skb_cb ovs_cb;
int err;
@@ -352,7 +354,7 @@ static int queue_gso_packets(struct datapath *dp, struct
sk_buff *skb,
return PTR_ERR(segs);
if (segs == NULL)
return -EINVAL;
-
+#ifdef HAVE_SKB_GSO_UDP
if (gso_type & SKB_GSO_UDP) {
/* The initial flow key extracted by ovs_flow_key_extract()
* in this case is for a first fragment, so we need to
@@ -361,14 +363,15 @@ static int queue_gso_packets(struct datapath *dp, struct
sk_buff *skb,
later_key = *key;
later_key.ip.frag = OVS_FRAG_TYPE_LATER;
}
-
+#endif
/* Queue all of the segments. */
skb = segs;
do {
*OVS_CB(skb) = ovs_cb;
+#ifdef HAVE_SKB_GSO_UDP
if (gso_type & SKB_GSO_UDP && skb != segs)
key = &later_key;
-
+#endif
err = queue_userspace_packet(dp, skb, key, upcall_info, cutlen);
if (err)
break;
diff --git a/datapath/linux/compat/stt.c b/datapath/linux/compat/stt.c
index 37d5f4b..66a97f2 100644
--- a/datapath/linux/compat/stt.c
+++ b/datapath/linux/compat/stt.c
@@ -81,8 +81,13 @@ struct stt_dev {
#define STT_PROTO_TCP BIT(3)
#define STT_PROTO_TYPES(STT_PROTO_IPV4 | STT_PROTO_TCP)
+#ifdef HAVE_SKB_GSO_UDP
#define SUPPORTED_GSO_TYPES (SKB_GSO_TCPV4 | SKB_GSO_UDP | SKB_GSO_DODGY | \
SKB_GSO_TCPV6)
+#else
+#define SUPPORTED_GSO_TYPES (SKB_GSO_TCPV4 | SKB_GSO_DODGY | \
+SKB_GSO_TCPV6)
+#endif
/* The length and offset of a fragment are encoded in the sequence number.
* STT_SEQ_LEN_SHIFT is the left shift needed to store the length.
@@ -1310,7 +1315,7 @@ static bool validate_checksum(struct sk_buff *skb)
static bool set_offloads(struct sk_buff *skb)
{
struct stthdr *stth = stt_hdr(skb);
- unsigned short gso_type;
+ unsigned short gso_type = 0;
int l3_header_size;
int l4_header_size;
u16 csum_offset;
@@ -1351,7 +1356,9 @@ static bool set_offloads(struct sk_buff *skb)
case STT_PROTO_IPV4:
/* UDP/IPv4 */
csum_offset = offsetof(struct udphdr, check);
+#ifdef HAVE_SKB_GSO_UDP
gso_type = SKB_GSO_UDP;
+#endif
l3_header_size = sizeof(struct iphdr);
l4_header_size = sizeof(struct udphdr);
skb->protocol = htons(ETH_P_IP);
@@ -1359,7 +1366,9 @@ static bool set_offloads(struct sk_buff *skb)
default:
/* UDP/IPv6 */
csum_offset = offsetof(struct udphdr, check);
+#ifdef HAVE_SKB_GSO_UDP
gso_type = SKB_GSO_UDP;
+#endif
l3_header_size = sizeof(struct ipv6hdr);
l4_header_size = sizeof(struct udphdr);
skb->protocol = htons(ETH_P_IPV6);
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH V2 04/10] datapath: conntrack: make protocol tracker pointers const
From: Florian Westphal
Upstream commit:
commit b3480fe059ac9121b5714205b4ddae14b59ef4be
Author: Florian Westphal
Date: Sat Aug 12 00:57:08 2017 +0200
netfilter: conntrack: make protocol tracker pointers const
Doesn't change generated code, but will make it easier to eventually
make the actual trackers themselvers const.
Signed-off-by: Florian Westphal
Signed-off-by: Pablo Neira Ayuso
Cc: Florian Westphal
Signed-off-by: Greg Rose
---
datapath/conntrack.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/datapath/conntrack.c b/datapath/conntrack.c
index 3f79433..a75ae3c 100644
--- a/datapath/conntrack.c
+++ b/datapath/conntrack.c
@@ -613,8 +613,8 @@ static struct nf_conn *
ovs_ct_find_existing(struct net *net, const struct nf_conntrack_zone *zone,
u8 l3num, struct sk_buff *skb, bool natted)
{
- struct nf_conntrack_l3proto *l3proto;
- struct nf_conntrack_l4proto *l4proto;
+ const struct nf_conntrack_l3proto *l3proto;
+ const struct nf_conntrack_l4proto *l4proto;
struct nf_conntrack_tuple tuple;
struct nf_conntrack_tuple_hash *h;
struct nf_conn *ct;
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH V2 03/10] compat:inet_frag.h: Check for frag_percpu_counter_batch
Fix up the compat layer to check for frag_percpu_counter_batch and
if not present then use atomic_sub and atomic_add as per the
backport in the 3.16.50 LTS kernel.
Signed-off-by: Greg Rose
---
datapath/linux/compat/include/net/inet_frag.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/datapath/linux/compat/include/net/inet_frag.h
b/datapath/linux/compat/include/net/inet_frag.h
index 34078c8..4090886 100644
--- a/datapath/linux/compat/include/net/inet_frag.h
+++ b/datapath/linux/compat/include/net/inet_frag.h
@@ -30,6 +30,7 @@ static inline bool inet_frag_evicting(struct inet_frag_queue
*q)
#endif
#ifndef HAVE_SUB_FRAG_MEM_LIMIT_ARG_STRUCT_NETNS_FRAGS
+#ifdef frag_percpu_counter_batch
static inline void rpl_sub_frag_mem_limit(struct netns_frags *nf, int i)
{
__percpu_counter_add(&nf->mem, -i, frag_percpu_counter_batch);
@@ -41,6 +42,19 @@ static inline void rpl_add_frag_mem_limit(struct netns_frags
*nf, int i)
__percpu_counter_add(&nf->mem, i, frag_percpu_counter_batch);
}
#define add_frag_mem_limit rpl_add_frag_mem_limit
+#else /* !frag_percpu_counter_batch */
+static inline void rpl_sub_frag_mem_limit(struct netns_frags *nf, int i)
+{
+ atomic_sub(i, &nf->mem);
+}
+#define sub_frag_mem_limit rpl_sub_frag_mem_limit
+
+static inline void rpl_add_frag_mem_limit(struct netns_frags *nf, int i)
+{
+ atomic_add(i, &nf->mem);
+}
+#define add_frag_mem_limit rpl_add_frag_mem_limit
+#endif /* frag_percpu_counter_batch */
#endif
#ifdef HAVE_VOID_INET_FRAGS_INIT
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH V2 02/10] compat: Do not include headers when not compiling
If the entire file is not going to be compiled because OVS is using
upstream tunnel support then also don't bother pulling in the headers.
Signed-off-by: Greg Rose
---
datapath/linux/compat/ip_gre.c| 2 +-
datapath/linux/compat/ip_output.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/datapath/linux/compat/ip_gre.c b/datapath/linux/compat/ip_gre.c
index 94fdaa9..4e32591 100644
--- a/datapath/linux/compat/ip_gre.c
+++ b/datapath/linux/compat/ip_gre.c
@@ -12,6 +12,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#ifndef USE_UPSTREAM_TUNNEL
#include
#include
#include
@@ -52,7 +53,6 @@
#include
#include
-#ifndef USE_UPSTREAM_TUNNEL
#if IS_ENABLED(CONFIG_IPV6)
#include
#include
diff --git a/datapath/linux/compat/ip_output.c
b/datapath/linux/compat/ip_output.c
index edca340..e2f869f 100644
--- a/datapath/linux/compat/ip_output.c
+++ b/datapath/linux/compat/ip_output.c
@@ -45,6 +45,7 @@
* Hirokazu Takahashi: sendfile() on UDP works now.
*/
+#ifndef HAVE_CORRECT_MRU_HANDLING
#include
#include
#include
@@ -82,7 +83,6 @@
#include
#include
-#ifndef HAVE_CORRECT_MRU_HANDLING
static inline void rpl_ip_options_fragment(struct sk_buff *skb)
{
unsigned char *optptr = skb_network_header(skb) + sizeof(struct iphdr);
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH V2 01/10] datapath: Fix netdev_master_upper_dev_link for 4.14
An extended netlink ack has been added for 4.14 - add compat layer
changes so that it compiles for all kernels up to and including
4.14.
Signed-off-by: Greg Rose
---
acinclude.m4| 3 +++
datapath/linux/compat/include/linux/netdevice.h | 30 +
datapath/vport-netdev.c | 3 ++-
3 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/acinclude.m4 b/acinclude.m4
index c04c2c6..768c20c 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -795,6 +795,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
[OVS_DEFINE([HAVE_LIST_IN_NF_HOOK_OPS])])
OVS_GREP_IFELSE([$KSRC/include/uapi/linux/netfilter/nf_conntrack_common.h],
[IP_CT_UNTRACKED])
+ OVS_FIND_PARAM_IFELSE([$KSRC/include/linux/netdevice.h],
+[netdev_master_upper_dev_link], [extack],
+[OVS_DEFINE([HAVE_UPPER_DEV_LINK_EXTACK])])
if cmp -s datapath/linux/kcompat.h.new \
datapath/linux/kcompat.h >/dev/null 2>&1; then
diff --git a/datapath/linux/compat/include/linux/netdevice.h
b/datapath/linux/compat/include/linux/netdevice.h
index 3c3cf42..25d5d3a 100644
--- a/datapath/linux/compat/include/linux/netdevice.h
+++ b/datapath/linux/compat/include/linux/netdevice.h
@@ -101,14 +101,36 @@ static inline bool netif_needs_gso(struct sk_buff *skb,
#ifndef HAVE_NETDEV_MASTER_UPPER_DEV_LINK_RH
static inline int rpl_netdev_master_upper_dev_link(struct net_device *dev,
struct net_device *upper_dev,
- void *upper_priv, void
*upper_info)
+ void *upper_priv,
+ void *upper_info, void *extack)
{
return netdev_master_upper_dev_link(dev, upper_dev);
}
#define netdev_master_upper_dev_link rpl_netdev_master_upper_dev_link
-
-#endif
-#endif
+#else /* #ifndef HAVE_NETDEV_MASTER_UPPER_DEV_LINK_RH */
+static inline int rpl_netdev_master_upper_dev_link(struct net_device *dev,
+ struct net_device *upper_dev,
+ void *upper_priv,
+ void *upper_info, void *extack)
+{
+ return netdev_master_upper_dev_link(dev, upper_dev,
+ upper_priv, upper_info);
+}
+#define netdev_master_upper_dev_link rpl_netdev_master_upper_dev_link
+#endif /* #else HAVE_NETDEV_MASTER_UPPER_DEV_LINK_RH */
+#else /* #ifndef HAVE_NETDEV_MASTER_UPPER_DEV_LINK_PRIV */
+#ifndef HAVE_UPPER_DEV_LINK_EXTACK
+static inline int rpl_netdev_master_upper_dev_link(struct net_device *dev,
+ struct net_device *upper_dev,
+ void *upper_priv,
+ void *upper_info, void *extack)
+{
+ return netdev_master_upper_dev_link(dev, upper_dev, upper_priv,
+ upper_info);
+}
+#define netdev_master_upper_dev_link rpl_netdev_master_upper_dev_link
+#endif /* #ifndef HAVE_UPPER_DEV_LINK_EXTACK */
+#endif /* #else HAVE_NETDEV_MASTER_UPPER_DEV_LINK_PRIV */
#if LINUX_VERSION_CODE < KERNEL_VERSION(3,16,0)
#define dev_queue_xmit rpl_dev_queue_xmit
diff --git a/datapath/vport-netdev.c b/datapath/vport-netdev.c
index 697c442..4eb8816 100644
--- a/datapath/vport-netdev.c
+++ b/datapath/vport-netdev.c
@@ -113,7 +113,8 @@ struct vport *ovs_netdev_link(struct vport *vport, const
char *name)
rtnl_lock();
err = netdev_master_upper_dev_link(vport->dev,
- get_dpdev(vport->dp), NULL, NULL);
+ get_dpdev(vport->dp),
+ NULL, NULL, NULL);
if (err)
goto error_unlock;
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH V2 00/10] Upstream Linux bug fixes for datapath
Reorganized patch set that includes bug fixes and compatability layer changes that can be backported to 2.9 as well as applied to master. V2 of these patches include suggested changes from the first patch set. Arnd Bergmann (1): datapath: use ktime_get_ts64() instead of ktime_get_ts() Christophe JAILLET (1): datapath: Fix an error handling path in 'ovs_nla_init_match_and_action() Florian Westphal (1): datapath: conntrack: make protocol tracker pointers const Greg Rose (5): datapath: Fix netdev_master_upper_dev_link for 4.14 compat: Do not include headers when not compiling compat:inet_frag.h: Check for frag_percpu_counter_batch datapath: Fix SKB_GSO_UDP usage compat: Fix compiler headers Gustavo A. R. Silva (1): datapath: fix data type in queue_gso_packets zhangliping (1): datapath: fix the incorrect flow action alloc size acinclude.m4 | 9 +++ datapath/conntrack.c | 4 +-- datapath/datapath.c| 14 ++ datapath/flow.c| 7 ++--- datapath/flow_netlink.c| 16 ++-- datapath/linux/Modules.mk | 1 + datapath/linux/compat/include/linux/compiler-gcc.h | 2 ++ datapath/linux/compat/include/linux/netdevice.h| 30 +++--- datapath/linux/compat/include/linux/timekeeping.h | 11 datapath/linux/compat/include/net/inet_frag.h | 14 ++ datapath/linux/compat/ip_gre.c | 2 +- datapath/linux/compat/ip_output.c | 2 +- datapath/linux/compat/stt.c| 11 +++- datapath/vport-netdev.c| 3 ++- 14 files changed, 100 insertions(+), 26 deletions(-) create mode 100644 datapath/linux/compat/include/linux/timekeeping.h -- 1.8.3.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [RFC] dpif-netlink: don't allocate per port netlink sockets
On Tue, 23 Jan 2018 09:50:00 -0800, Ben Pfaff wrote: > Per-port sockets help OVS to improve fairness, so that a single busy > port can't monopolize all slow-path resources. We can't just throw that > away. If there's a problem with too many netlink sockets, let's come up > with a solution, but it can't be to eliminate fairness entirely. The main problem with this is the sockets are dedicated to particular ports. With high number of ports, the number of sockets raises to such high value that it stops helping performance anyway. There's not much point of having thousands opened sockets per CPU, we'll not be able to utilize them anyway. Having dedicated sockets for each port is wasteful, especially if one port is very busy with upcalls and other ports are mostly idle. (And if many ports are busy with many upcalls, we're in performance troubles anyway.) It would make sense to share the sockets between the ports. I'd like to understand more about the thoughts behind the fairness. Why should not a single busy port use all slow-path resources in case other ports are idle? Thanks, Jiri ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] question about dp_packet lifetime
Hi, My name is Alessandro Rosetti, and I'm currently adding netmap support to ovs, following an approach similar to DPDK. I've created a new netdev: netdev_netmap that uses the pmd infrastructure. The prototype I have seems to work fine (I still need to tune performance, test optional features, and test more complex topologies.) I have a question about the lifetime of dp_packets. Is there any guarantee that the dp_packets allocated in a receive callback (e.g. netdev_netmap_rxq_recv) are consumed by OVS (e.g. dropped, cloned, or sent to other ports) **before** a subsequent call to the receive callback (on the same port)? Or is it possible for dp_packets to be stored somewhere (e.g. in an OVS internal queue) and live across subsequent invocations of the receive callback that allocated them? I need to know if this is the case to check that my current prototype is safe. I use per-port pre-allocation of dp_packets, for maximum performance. I've seen that DPDK uses its internal allocator to allocate and deallocate dp_packets, but netmap does not expose one. Each packet received with netmap is created as a new type dp_packet: DPBUF_NETMAP. The data points to a netmap buffer (preallocated by the kernel). When I receive data (netdev_netmap_rxq_recv) I reuse the dp_packets, updating the internal pointer and a couple of additional informations stored inside the dp_packet. When I have to send data I use zero copy if dp_packet is DPBUF_NETMAP and copy if it's not. Thanks for the help! Alessandro. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 3/3] expr: Add additional invariant check in test.
On Tue, Feb 6, 2018 at 11:30 PM, Ben Pfaff wrote:
> Signed-off-by: Ben Pfaff
>
Acked-by: Numan Siddique
Thanks
Numan
> ---
> tests/test-ovn.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tests/test-ovn.c b/tests/test-ovn.c
> index d4dfc8151d9e..74527531870d 100644
> --- a/tests/test-ovn.c
> +++ b/tests/test-ovn.c
> @@ -871,6 +871,7 @@ test_tree_shape_exhaustively(struct expr *expr,
> struct shash *symtab,
>
> if (operation >= OP_NORMALIZE) {
> modified = expr_normalize(modified);
> +ovs_assert(expr_honors_invariants(modified));
> ovs_assert(expr_is_normalized(modified));
> }
> }
> --
> 2.15.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 2/3] expr: Make expr_sort() always yield an expr that satisfies invariants.
On Tue, Feb 6, 2018 at 11:30 PM, Ben Pfaff wrote:
> Expressions of type EXPR_T_AND are supposed to follow an invariant that
> they have at least 2 clauses, but expr_sort() did not always follow that;
> for example, applying it to (x[0] == 1 && x[1] == 1) yielded the 1-child
> EXPR_T_AND expression x[0..1] == 3. This commit fixes the problem.
>
> I don't know of any externally visible negative consequences for this
> problem, but it made the code harder to reason about.
>
> Signed-off-by: Ben Pfaff
>
Acked-by: Numan Siddique
Thanks
Numan
> ---
> ovn/lib/expr.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/ovn/lib/expr.c b/ovn/lib/expr.c
> index 108af4a48210..b0aa6726b5e0 100644
> --- a/ovn/lib/expr.c
> +++ b/ovn/lib/expr.c
> @@ -2366,9 +2366,19 @@ crush_cmps(struct expr *expr, const struct
> expr_symbol *symbol)
> }
> }
>
> +/* Applied to an EXPR_T_AND 'expr' whose subexpressions are in terms of
> only
> + * EXPR_T_CMP, EXPR_T_AND, and EXPR_T_OR, this takes ownership of 'expr'
> and
> + * returns a new expression in terms of EXPR_T_CMP, EXPR_T_AND,
> EXPR_T_OR, or
> + * EXPR_T_BOOLEAN.
> + *
> + * The function attempts to bring together and combine clauses of the
> original
> + * 'expr' that were in terms of a single variable. For example, it
> combines
> + * (x[0] == 1 && x[1] == 1) into the single x[0..1] == 3. */
> static struct expr *
> expr_sort(struct expr *expr)
> {
> +ovs_assert(expr->type == EXPR_T_AND);
> +
> size_t n = ovs_list_size(&expr->andor);
> struct expr_sort *subs = xmalloc(n * sizeof *subs);
> struct expr *sub;
> @@ -2386,6 +2396,9 @@ expr_sort(struct expr *expr)
> qsort(subs, n, sizeof *subs, compare_expr_sort);
>
> ovs_list_init(&expr->andor);
> +free(expr);
> +expr = NULL;
> +
> for (i = 0; i < n; ) {
> if (subs[i].symbol) {
> size_t j;
> @@ -2438,11 +2451,8 @@ static struct expr *expr_normalize_or(struct expr
> *expr);
> static struct expr *
> expr_normalize_and(struct expr *expr)
> {
> -ovs_assert(expr->type == EXPR_T_AND);
> -
> expr = expr_sort(expr);
> if (expr->type != EXPR_T_AND) {
> -ovs_assert(expr->type == EXPR_T_BOOLEAN);
> return expr;
> }
>
> --
> 2.15.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/3] expr: Fix some bad naming.
On Tue, Feb 6, 2018 at 11:30 PM, Ben Pfaff wrote:
> expr_is_cmp() was badly named because it didn't just check for whether its
> argument was an EXPR_T_CMP node.
>
> struct expr_sort's 'relop' member was badly named because it wasn't a
> relational operator, it was a symbol.
>
> This commit improves both names.
>
> Signed-off-by: Ben Pfaff
>
Acked-by: Numan Siddique
Thanks
Numan
> ---
> ovn/lib/expr.c | 46 ++
> 1 file changed, 26 insertions(+), 20 deletions(-)
>
> diff --git a/ovn/lib/expr.c b/ovn/lib/expr.c
> index 79ff45762f65..108af4a48210 100644
> --- a/ovn/lib/expr.c
> +++ b/ovn/lib/expr.c
> @@ -1922,8 +1922,13 @@ expr_simplify(struct expr *expr,
> OVS_NOT_REACHED();
> }
>
> +/* Tests whether 'expr' is an expression over exactly one symbol: that is,
> + * whether it is either a EXPR_T_CMP node or a tree of ANDs and ORs all
> over
> + * the same symbol. If it is, returns the symbol in question. If it is
> not
> + * (that is, if there is more than one symbol or no symbols at all),
> returns
> + * NULL. */
> static const struct expr_symbol *
> -expr_is_cmp(const struct expr *expr)
> +expr_get_unique_symbol(const struct expr *expr)
> {
> switch (expr->type) {
> case EXPR_T_CMP:
> @@ -1935,7 +1940,7 @@ expr_is_cmp(const struct expr *expr)
> struct expr *sub;
>
> LIST_FOR_EACH (sub, node, &expr->andor) {
> -const struct expr_symbol *symbol = expr_is_cmp(sub);
> +const struct expr_symbol *symbol =
> expr_get_unique_symbol(sub);
> if (!symbol || (prev && symbol != prev)) {
> return NULL;
> }
> @@ -1955,7 +1960,7 @@ expr_is_cmp(const struct expr *expr)
>
> struct expr_sort {
> struct expr *expr;
> -const struct expr_symbol *relop;
> +const struct expr_symbol *symbol;
> enum expr_type type;
> };
>
> @@ -1967,8 +1972,8 @@ compare_expr_sort(const void *a_, const void *b_)
>
> if (a->type != b->type) {
> return a->type < b->type ? -1 : 1;
> -} else if (a->relop) {
> -int cmp = strcmp(a->relop->name, b->relop->name);
> +} else if (a->symbol) {
> +int cmp = strcmp(a->symbol->name, b->symbol->name);
> if (cmp) {
> return cmp;
> }
> @@ -2330,10 +2335,10 @@ crush_or(struct expr *expr, const struct
> expr_symbol *symbol)
> return expr_fix(expr);
> }
>
> -/* Takes ownership of 'expr', which must be a cmp in the sense determined
> by
> - * 'expr_is_cmp(expr)', where 'symbol' is the symbol returned by that
> function.
> - * Returns an equivalent expression owned by the caller that is a single
> - * EXPR_T_CMP or a disjunction of them or a EXPR_T_BOOLEAN. */
> +/* Takes ownership of 'expr', which must have a unique symbol in the
> sense of
> + * 'expr_get_unique_symbol(expr)', where 'symbol' is the symbol returned
> by
> + * that function. Returns an equivalent expression owned by the caller
> that is
> + * a single EXPR_T_CMP or a disjunction of them or a EXPR_T_BOOLEAN. */
> static struct expr *
> crush_cmps(struct expr *expr, const struct expr_symbol *symbol)
> {
> @@ -2372,8 +2377,8 @@ expr_sort(struct expr *expr)
> i = 0;
> LIST_FOR_EACH (sub, node, &expr->andor) {
> subs[i].expr = sub;
> -subs[i].relop = expr_is_cmp(sub);
> -subs[i].type = subs[i].relop ? EXPR_T_CMP : sub->type;
> +subs[i].symbol = expr_get_unique_symbol(sub);
> +subs[i].type = subs[i].symbol ? EXPR_T_CMP : sub->type;
> i++;
> }
> ovs_assert(i == n);
> @@ -2382,17 +2387,17 @@ expr_sort(struct expr *expr)
>
> ovs_list_init(&expr->andor);
> for (i = 0; i < n; ) {
> -if (subs[i].relop) {
> +if (subs[i].symbol) {
> size_t j;
> for (j = i + 1; j < n; j++) {
> -if (subs[i].relop != subs[j].relop) {
> +if (subs[i].symbol != subs[j].symbol) {
> break;
> }
> }
>
> struct expr *crushed;
> if (j == i + 1) {
> -crushed = crush_cmps(subs[i].expr, subs[i].relop);
> +crushed = crush_cmps(subs[i].expr, subs[i].symbol);
> } else {
> struct expr *combined = subs[i].expr;
> for (size_t k = i + 1; k < j; k++) {
> @@ -2400,7 +2405,7 @@ expr_sort(struct expr *expr)
> subs[k].expr);
> }
> ovs_assert(!ovs_list_is_short(&combined->andor));
> -crushed = crush_cmps(combined, subs[i].relop);
> +crushed = crush_cmps(combined, subs[i].symbol);
> }
> if (crushed->type == EXPR_T_BOOLEAN) {
> if (!crushed->boolean) {
> @@ -2472,7 +2477,7 @@ expr_normalize_and(struct expr *expr)
> }
>
> ovs_assert(sub->type == EXPR_T_OR);
> -const struct expr_symbol *
Re: [ovs-dev] [ovs-dev, ovs-dev, v4] netdev-dpdk: Configurable Link State Change (LSC) detection mode
I support the idea to remove the global default configuration option. It causes more confusion that it helps. If at all, new physical ports are typically added to OVS manually and LSC interrupt mode can be configured as required. Configurable defaults can make sense for vhostuser ports as they are created automatically from OpenStack. The operator wants to control default settings per port in the absence of specific configuration coming from OpenStack. Regards, Jan > -Original Message- > From: ovs-dev-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Eelco Chaudron > Sent: Tuesday, 06 February, 2018 17:30 > To: Ilya Maximets ; Róbert Mulik > ; d...@openvswitch.org > Subject: Re: [ovs-dev] [ovs-dev, ovs-dev, v4] netdev-dpdk: Configurable Link > State Change (LSC) detection mode > > On 06/02/18 16:01, Ilya Maximets wrote: > > On 06.02.2018 16:47, Eelco Chaudron wrote: > >> On 06/02/18 13:12, Ilya Maximets wrote: > >>> On 05.02.2018 19:29, Eelco Chaudron wrote: > On 02/02/18 17:17, Ilya Maximets wrote: > > On 02.02.2018 17:05, Róbert Mulik wrote: > >> It is possible to change LSC detection mode to polling or interrupt > >> mode > >> for DPDK interfaces. The default is polling mode. To set interrupt > >> mode, > >> option dpdk-lsc-interrupt has to be set to true. > >> > >> In polling mode more processor time is needed, since the OVS > >> repeatedly reads > >> the link state with a short period. It can lead to packet loss for > >> certain > >> systems. > >> > >> In interrupt mode the hardware itself triggers an interrupt when link > >> state > >> change happens, so less processing time needs for the OVS. It is not > >> possible > >> to enable the interrupt mode on all hardware. > >> > >> For detailed description and usage see the dpdk install documentation. > >> > >> Signed-off-by: Robert Mulik > >> Reviewed-by: Ilya Maximets > > 8< SNIP >8 > >> diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c > >> index f44f950..87608a5 100644 > >> --- a/vswitchd/bridge.c > >> +++ b/vswitchd/bridge.c > >> @@ -68,6 +68,9 @@ > >> #include "lib/vswitch-idl.h" > >> #include "xenserver.h" > >> #include "vlan-bitmap.h" > >> +#ifdef DPDK_NETDEV > >> +#include "./lib/netdev-provider.h" > >> +#endif > >> > >> VLOG_DEFINE_THIS_MODULE(bridge); > >> > >> @@ -601,6 +604,11 @@ bridge_reconfigure(const struct > >> ovsrec_open_vswitch *ovs_cfg) > >> ofproto_set_vlan_limit(smap_get_int(&ovs_cfg->other_config, > >> "vlan-limit", > >> LEGACY_MAX_VLAN_HEADERS)); > >> > >> +#ifdef DPDK_NETDEV > >> + netdev_dpdk_set_def_lsc_int_mode_enabled( > >> + smap_get_bool(&ovs_cfg->other_config, "dpdk-lsc-interrupt", > >> false)); > >> +#endif > >> + > > I'm still thinking that this is not necessary. > > Eelco, why do you think we need to change the default global value in > > run-time? > > IMHO, this only complicates the code. (I didn't check, but it looks > > like current > > implementation will not work anyway.) > > > I do feel like the global option should be applied directly for the > following reasons: > > - There is no way to see what is the running configuration > - If not done this way the LSC mode might change for some devices, for > example if you decide to change another port related > configuration. > > >>> I feel that we have some kind of misunderstanding. > >>> I'll try to explain my position: > >>> > >>> 1. I'm not against the global config option. I just want it to be static. > >>> i.e. OVS restart will be required to change it. > >> Got your point, but why do you want it to be static? I'm arguing against it > >> as other options, like other_config:pmd-cpu-mask, are also not static. > >> If it can be done dynamic, I prefer doing it that way. > > 'pmd-cpu-mask' change is the only way to configure the number of PMD > > threads, > > and this is important to have this dynamic for run-time scaling. Also, this > > is > > the datapath parameter, not the parameter of any ports. We, actually, have > > no > > dynamic global parameters for ports. All the ports related parameters like > > iommu-support, vhost_sock_dir are static or hardcoded. > > > > other_config:dpdk-lsc-interrupt is just the default value that could be > > overridden by the dynamic per-port configuration. We're not frequently > > adding new physical NICs to servers. At this point user likely knows, which > > devices supports LSC interrupts and which are not, and it's possible to > > decide > > which value for default other_config:dpdk-lsc-interrupt is preferable. > > > > I personally prefer to not have global option. Only per-port configurable > > with 'false' as
[ovs-dev] porting Open vSwitch to supermicro swithes
Dear colleagues, please tell me whether it is possible to porting your solution Open vSwitch for SDN Switches from Supermicro such as SSE-X3648S, x86_64 Broadcom Trident2 and SSE-G3648B x86_64 Broadcom Helix4 ? Best Regards, Oleg Matsiyevich QUIP PRO LLP. ol...@quippro.kz olegm...@inbox.com olegm...@gmail.com 299 Tole Bi St. Floor 4 Almaty, Kazakhstan 050061 tel: +7-(727)-243-04-38 tel: +7-(727)-243-04-47 fax: +7-(727)-238-13-20 gsm: +7-(777)-230-22-41 web: www.quippro.kz Skype name: pangolin320 ICQ ID: 106820800 mailto:olegm...@gmail.com ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v7 0/6] OVS-DPDK flow offload with rte_flow
> -Original Message- > From: Yuanhan Liu [mailto:y...@fridaylinux.org] > Sent: Wednesday, February 7, 2018 9:37 AM > To: Stokes, Ian > Cc: Flavio Leitner ; d...@openvswitch.org; Simon Horman > ; Olga Shern ; Shahaf > Shuler > Subject: Re: [ovs-dev] [PATCH v7 0/6] OVS-DPDK flow offload with rte_flow > > On Wed, Feb 07, 2018 at 09:24:52AM +, Stokes, Ian wrote: > > > -Original Message- > > > From: Yuanhan Liu [mailto:y...@fridaylinux.org] > > > Sent: Wednesday, February 7, 2018 2:12 AM > > > To: Stokes, Ian > > > Cc: Flavio Leitner ; d...@openvswitch.org; Simon > > > Horman ; Olga Shern > > > ; Shahaf Shuler > > > Subject: Re: [ovs-dev] [PATCH v7 0/6] OVS-DPDK flow offload with > > > rte_flow > > > > > > On Tue, Feb 06, 2018 at 09:34:36PM +, Stokes, Ian wrote: > > > > > -Original Message- > > > > > From: Yuanhan Liu [mailto:y...@fridaylinux.org] > > > > > Sent: Tuesday, February 6, 2018 9:10 AM > > > > > To: Flavio Leitner ; Stokes, Ian > > > > > > > > > > Cc: d...@openvswitch.org; Simon Horman > > > > > > > > > > Subject: Re: [ovs-dev] [PATCH v7 0/6] OVS-DPDK flow offload with > > > > > rte_flow > > > > > > > > > > On Thu, Feb 01, 2018 at 01:35:15AM -0200, Flavio Leitner wrote: > > > > > > On Mon, Jan 29, 2018 at 02:59:42PM +0800, Yuanhan Liu wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Here is a joint work from Mellanox and Napatech, to enable > > > > > > > the flow hw offload with the DPDK generic flow interface > (rte_flow). > > > > > > > > > > > > > > The basic idea is to associate the flow with a mark id (a > > > > > > > unit32_t > > > > > number). > > > > > > > Later, we then get the flow directly from the mark id, which > > > > > > > could bypass some heavy CPU operations, including but not > > > > > > > limiting to mini flow extract, emc lookup, dpcls lookup, etc. > > > > > > > > > > > > > > The association is done with CMAP in patch 1. The CPU > > > > > > > workload bypassing is done in patch 2. The flow offload is > > > > > > > done in patch 3, which mainly does two things: > > > > > > > > > > > > > > - translate the ovs match to DPDK rte flow patterns > > > > > > > - bind those patterns with a RSS + MARK action. > > > > > > > > > > > > > > Patch 5 makes the offload work happen in another thread, for > > > > > > > leaving the datapath as light as possible. > > > > > > > > > > > > > > A PHY-PHY forwarding with 1000 mega flows > > > > > > > (udp,tp_src=1000-1999) and > > > > > > > 1 million streams (tp_src=1000-1999, tp_dst=2000-2999) show > > > > > > > more than 260% performance boost. > > > > > > > > > > > > > > Note that it's disabled by default, which can be enabled by: > > > > > > > > > > > > Hi, > > > > > > > > > > > > First of all, thanks for working on this feature. > > > > > > > > > > > > I have some general comments I'd like to discuss before going > > > > > > deeper on it. > > > > > > > > > > > > The documentation is too simple. It should mention the HW > > > > > > requirements in order to use this feature. > > > > > > > > > > It listed the NICs that support this feature. > > > > > > > > > > > Also some important limitations, like no support for IP > > > > > > frags, MPLS or conntrack, for instance. > > > > > > > > > > Yes, that could be added. > > > > > > > > > > > It seems it would be possible to leave the HW offloading code > > > > > > outside of dpif-netdev.c which is quite long already. I hope > > > > > > it will improve isolation and code clarity too. > > > > > > > > > > Yes. My thoughts was we can do it later, when we are going to > > > > > add some other flow models (say, full offload) in future. > > > > > Moreover, it seems that it's a custom in OVS to have long source > > > > > code files. I was just following it. > > > > > > > > > > But I hve no objections to break it. Ian, should I break it now? > > > > > What's your plan to merge it? > > > > > > > > Hi Yuanhan, I believe I gave the same feedback on the first review > > > > pass > > > I did. Previously I was happy to hold off on this work in order to > > > make it into the 2.9 release but as that window has passed I think > > > it makes sense to break it out now. It will save the refactor work > later. > > > > > > So it won't in ovs 2.9 release? > > > > No, the code freeze was the 31st of January for new features. Only bug > fixes are accepted for the remaining 2.9 window. This would be part of > the 2.10 release. > > I thought we all come an agreement that this will be part of 2.9 release > as a experimental feature. What made we missed it? So there was agreement the feature would be experimental when it is upstreamed to master (not just for OVS 2.9). Unfortunately it missed the 2.9 deadline due to the lack of reviews external to authors within community. I was hoping to review it myself in the run up to the 31st however a separate issue relating to dpdk mempools took priority as it was a blocking issue for users upgrading from OVS 2.8 to OVS 2.9. It was raised by the
Re: [ovs-dev] [PATCH v7 0/6] OVS-DPDK flow offload with rte_flow
On Wed, Feb 07, 2018 at 09:24:52AM +, Stokes, Ian wrote: > > -Original Message- > > From: Yuanhan Liu [mailto:y...@fridaylinux.org] > > Sent: Wednesday, February 7, 2018 2:12 AM > > To: Stokes, Ian > > Cc: Flavio Leitner ; d...@openvswitch.org; Simon Horman > > ; Olga Shern ; Shahaf > > Shuler > > Subject: Re: [ovs-dev] [PATCH v7 0/6] OVS-DPDK flow offload with rte_flow > > > > On Tue, Feb 06, 2018 at 09:34:36PM +, Stokes, Ian wrote: > > > > -Original Message- > > > > From: Yuanhan Liu [mailto:y...@fridaylinux.org] > > > > Sent: Tuesday, February 6, 2018 9:10 AM > > > > To: Flavio Leitner ; Stokes, Ian > > > > > > > > Cc: d...@openvswitch.org; Simon Horman > > > > Subject: Re: [ovs-dev] [PATCH v7 0/6] OVS-DPDK flow offload with > > > > rte_flow > > > > > > > > On Thu, Feb 01, 2018 at 01:35:15AM -0200, Flavio Leitner wrote: > > > > > On Mon, Jan 29, 2018 at 02:59:42PM +0800, Yuanhan Liu wrote: > > > > > > Hi, > > > > > > > > > > > > Here is a joint work from Mellanox and Napatech, to enable the > > > > > > flow hw offload with the DPDK generic flow interface (rte_flow). > > > > > > > > > > > > The basic idea is to associate the flow with a mark id (a > > > > > > unit32_t > > > > number). > > > > > > Later, we then get the flow directly from the mark id, which > > > > > > could bypass some heavy CPU operations, including but not > > > > > > limiting to mini flow extract, emc lookup, dpcls lookup, etc. > > > > > > > > > > > > The association is done with CMAP in patch 1. The CPU workload > > > > > > bypassing is done in patch 2. The flow offload is done in patch > > > > > > 3, which mainly does two things: > > > > > > > > > > > > - translate the ovs match to DPDK rte flow patterns > > > > > > - bind those patterns with a RSS + MARK action. > > > > > > > > > > > > Patch 5 makes the offload work happen in another thread, for > > > > > > leaving the datapath as light as possible. > > > > > > > > > > > > A PHY-PHY forwarding with 1000 mega flows (udp,tp_src=1000-1999) > > > > > > and > > > > > > 1 million streams (tp_src=1000-1999, tp_dst=2000-2999) show more > > > > > > than 260% performance boost. > > > > > > > > > > > > Note that it's disabled by default, which can be enabled by: > > > > > > > > > > Hi, > > > > > > > > > > First of all, thanks for working on this feature. > > > > > > > > > > I have some general comments I'd like to discuss before going > > > > > deeper on it. > > > > > > > > > > The documentation is too simple. It should mention the HW > > > > > requirements in order to use this feature. > > > > > > > > It listed the NICs that support this feature. > > > > > > > > > Also some important limitations, like no support for IP frags, > > > > > MPLS or conntrack, for instance. > > > > > > > > Yes, that could be added. > > > > > > > > > It seems it would be possible to leave the HW offloading code > > > > > outside of dpif-netdev.c which is quite long already. I hope it > > > > > will improve isolation and code clarity too. > > > > > > > > Yes. My thoughts was we can do it later, when we are going to add > > > > some other flow models (say, full offload) in future. Moreover, it > > > > seems that it's a custom in OVS to have long source code files. I > > > > was just following it. > > > > > > > > But I hve no objections to break it. Ian, should I break it now? > > > > What's your plan to merge it? > > > > > > Hi Yuanhan, I believe I gave the same feedback on the first review pass > > I did. Previously I was happy to hold off on this work in order to make it > > into the 2.9 release but as that window has passed I think it makes sense > > to break it out now. It will save the refactor work later. > > > > So it won't in ovs 2.9 release? > > No, the code freeze was the 31st of January for new features. Only bug fixes > are accepted for the remaining 2.9 window. This would be part of the 2.10 > release. I thought we all come an agreement that this will be part of 2.9 release as a experimental feature. What made we missed it? Thanks. --yliu ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v7 0/6] OVS-DPDK flow offload with rte_flow
> -Original Message- > From: Yuanhan Liu [mailto:y...@fridaylinux.org] > Sent: Wednesday, February 7, 2018 2:12 AM > To: Stokes, Ian > Cc: Flavio Leitner ; d...@openvswitch.org; Simon Horman > ; Olga Shern ; Shahaf > Shuler > Subject: Re: [ovs-dev] [PATCH v7 0/6] OVS-DPDK flow offload with rte_flow > > On Tue, Feb 06, 2018 at 09:34:36PM +, Stokes, Ian wrote: > > > -Original Message- > > > From: Yuanhan Liu [mailto:y...@fridaylinux.org] > > > Sent: Tuesday, February 6, 2018 9:10 AM > > > To: Flavio Leitner ; Stokes, Ian > > > > > > Cc: d...@openvswitch.org; Simon Horman > > > Subject: Re: [ovs-dev] [PATCH v7 0/6] OVS-DPDK flow offload with > > > rte_flow > > > > > > On Thu, Feb 01, 2018 at 01:35:15AM -0200, Flavio Leitner wrote: > > > > On Mon, Jan 29, 2018 at 02:59:42PM +0800, Yuanhan Liu wrote: > > > > > Hi, > > > > > > > > > > Here is a joint work from Mellanox and Napatech, to enable the > > > > > flow hw offload with the DPDK generic flow interface (rte_flow). > > > > > > > > > > The basic idea is to associate the flow with a mark id (a > > > > > unit32_t > > > number). > > > > > Later, we then get the flow directly from the mark id, which > > > > > could bypass some heavy CPU operations, including but not > > > > > limiting to mini flow extract, emc lookup, dpcls lookup, etc. > > > > > > > > > > The association is done with CMAP in patch 1. The CPU workload > > > > > bypassing is done in patch 2. The flow offload is done in patch > > > > > 3, which mainly does two things: > > > > > > > > > > - translate the ovs match to DPDK rte flow patterns > > > > > - bind those patterns with a RSS + MARK action. > > > > > > > > > > Patch 5 makes the offload work happen in another thread, for > > > > > leaving the datapath as light as possible. > > > > > > > > > > A PHY-PHY forwarding with 1000 mega flows (udp,tp_src=1000-1999) > > > > > and > > > > > 1 million streams (tp_src=1000-1999, tp_dst=2000-2999) show more > > > > > than 260% performance boost. > > > > > > > > > > Note that it's disabled by default, which can be enabled by: > > > > > > > > Hi, > > > > > > > > First of all, thanks for working on this feature. > > > > > > > > I have some general comments I'd like to discuss before going > > > > deeper on it. > > > > > > > > The documentation is too simple. It should mention the HW > > > > requirements in order to use this feature. > > > > > > It listed the NICs that support this feature. > > > > > > > Also some important limitations, like no support for IP frags, > > > > MPLS or conntrack, for instance. > > > > > > Yes, that could be added. > > > > > > > It seems it would be possible to leave the HW offloading code > > > > outside of dpif-netdev.c which is quite long already. I hope it > > > > will improve isolation and code clarity too. > > > > > > Yes. My thoughts was we can do it later, when we are going to add > > > some other flow models (say, full offload) in future. Moreover, it > > > seems that it's a custom in OVS to have long source code files. I > > > was just following it. > > > > > > But I hve no objections to break it. Ian, should I break it now? > > > What's your plan to merge it? > > > > Hi Yuanhan, I believe I gave the same feedback on the first review pass > I did. Previously I was happy to hold off on this work in order to make it > into the 2.9 release but as that window has passed I think it makes sense > to break it out now. It will save the refactor work later. > > So it won't in ovs 2.9 release? No, the code freeze was the 31st of January for new features. Only bug fixes are accepted for the remaining 2.9 window. This would be part of the 2.10 release. Thanks Ian > > --yliu > > > I should have more time later this week to continue reviewing, I'll > provide some more feedback on the rest of the patchset then. > > > > Thanks > > Ian > > > > > > > > > > > So far there is no synchronization between PMDs in the fast path. > > > > However, we got a new mutex to sync PMDs and a new thread to manage. > > > > Even without the patch adding the thread, there would be a new > > > > mutex in the fast path. It seems the slow path today causes > > > > issues, so maybe the whole upcall processing could be pushed to > > > > another thread. I realize this is outside of the scope of this > > > > patchset, but it is something we should consider. > > > > > > > > As an alternative solution, maybe we could use a DPDK ring to have > > > > a lockless way to push flows to the auxiliary thread. > > > > > > It could be an option, but it brings a hard dependency on DPDK. Note > > > that the netdev datapath could leave without DPDK, IIUC. > > > > > > > There are some memory allocations and deallocations in the fast > > > > path using OVS functions. Perhaps it is better to use rte_* > > > > functions instead (another reason to split the code out of > > > > dpif-netdev.c) > > > > > > Why do you think the one from DPDK is better? Also, it brings the > > > DPDK dependency to
