[ovs-dev] 答复: [PATCH] dpif-netdev:Delete port check in do_add_port
Ping...
-邮件原件-
发件人: Linhaifeng
发送时间: 2018年4月26日 15:13
收件人: d...@openvswitch.org
抄送: Linhaifeng
主题: [PATCH] dpif-netdev:Delete port check in do_add_port
It is not need check port exist in do_add_port
because it had check in port_add.
Change-Id: Ie66206b40e305cef5f5b20af765c3128ccec6782
Signed-off-by: Haifeng Lin
---
lib/dpif-netdev.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index be31fd0..f7976b1 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -1568,11 +1568,6 @@ do_add_port(struct dp_netdev *dp, const char *devname,
const char *type,
struct dp_netdev_port *port;
int error;
-/* Reject devices already in 'dp'. */
-if (!get_port_by_name(dp, devname, &port)) {
-return EEXIST;
-}
-
error = port_create(devname, type, port_no, &port);
if (error) {
return error;
--
1.8.5.2.msysgit.0
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/3] ovn-controller: Make 'ovs_remote' a local variable.
Thanks.
Reviewed-by: Yifeng Sun
On Wed, Apr 25, 2018 at 8:42 AM, Ben Pfaff wrote:
> There's not much value in making this a global since it's really just
> parsed in one function and used in another.
>
> Signed-off-by: Ben Pfaff
> ---
> ovn/controller/ovn-controller.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/ovn/controller/ovn-controller.c b/ovn/controller/ovn-
> controller.c
> index 27a092d13508..29b3f1cade0a 100644
> --- a/ovn/controller/ovn-controller.c
> +++ b/ovn/controller/ovn-controller.c
> @@ -74,7 +74,7 @@ static unixctl_cb_func inject_pkt;
>
> static void update_probe_interval(struct controller_ctx *,
>const char *ovnsb_remote);
> -static void parse_options(int argc, char *argv[]);
> +static char *parse_options(int argc, char *argv[]);
> OVS_NO_RETURN static void usage(void);
>
> /* Pending packet to be injected into connected OVS. */
> @@ -84,8 +84,6 @@ struct pending_pkt {
> char *flow_s;
> };
>
> -static char *ovs_remote;
> -
> struct local_datapath *
> get_local_datapath(const struct hmap *local_datapaths, uint32_t
> tunnel_key)
> {
> @@ -600,7 +598,7 @@ main(int argc, char *argv[])
> ovs_cmdl_proctitle_init(argc, argv);
> set_program_name(argv[0]);
> service_start(&argc, &argv);
> -parse_options(argc, argv);
> +char *ovs_remote = parse_options(argc, argv);
> fatal_ignore_sigpipe();
>
> daemonize_start(false);
> @@ -891,7 +889,7 @@ main(int argc, char *argv[])
> exit(retval);
> }
>
> -static void
> +static char *
> parse_options(int argc, char *argv[])
> {
> enum {
> @@ -954,6 +952,7 @@ parse_options(int argc, char *argv[])
> argc -= optind;
> argv += optind;
>
> +char *ovs_remote;
> if (argc == 0) {
> ovs_remote = xasprintf("unix:%s/db.sock", ovs_rundir());
> } else if (argc == 1) {
> @@ -962,6 +961,7 @@ parse_options(int argc, char *argv[])
> VLOG_FATAL("exactly zero or one non-option argument required; "
> "use --help for usage");
> }
> +return ovs_remote;
> }
>
> static void
> --
> 2.16.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Administración Efectica del tiempo
Administración Efectica del tiempo para GERENTES o SUPERVISORES. Fecha: 17/Mayo/2018 Horario: 10:00 a 13:00 y 15:00 a 18:00 horas "Elimine para siempre la frase “No nos alcanza el tiempo” " En este seminario online en vivo aprenderá: Aprenda a planificar y organizar. 10 Soluciones para el control. Tiempos y movimientos. Medición de la efectividad. Cómo controlar verdaderamente la jornada laboral. Responda este correo con el asunto Gerentes, con los siguientes datos: Nombre: Correo: Teléfono: Si lo que usted desea dejar de recibir este tipo de mensajes responder este correo con el asunto BAJA ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4 1/1] netdev-dpdk: don't enable scatter for jumbo RX support for nfp
On 04/27/2018 05:40 PM, Pablo Cascón wrote:
> Currently to RX jumbo packets fails for NICs not supporting scatter.
> Scatter is not strictly needed for jumbo RX support. This change fixes
> the issue by not enabling scatter only for the PMD/NIC known not to
> need it to support jumbo RX.
>
Acked-by: Kevin Traynor
> Note: this change is temporary and not needed for later releases OVS/DPDK
>
> Reported-by: Louis Peens
> Signed-off-by: Pablo Cascón
> Reviewed-by: Simon Horman
> ---
> lib/netdev-dpdk.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index ee39cbe..fdc8f66 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -694,11 +694,19 @@ dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev, int
> n_rxq, int n_txq)
> int diag = 0;
> int i;
> struct rte_eth_conf conf = port_conf;
> +struct rte_eth_dev_info info;
>
> -/* For some NICs (e.g. Niantic), scatter_rx mode needs to be explicitly
> - * enabled. */
> +/* As of DPDK 17.11.1 a few PMDs require to explicitly enable
> + * scatter to support jumbo RX. Checking the offload capabilities
> + * is not an option as PMDs are not required yet to report
> + * them. The only reliable info is the driver name and knowledge
> + * (testing or code review). Listing all such PMDs feels harder
> + * than highlighting the one known not to need scatter */
> if (dev->mtu > ETHER_MTU) {
> -conf.rxmode.enable_scatter = 1;
> +rte_eth_dev_info_get(dev->port_id, &info);
> +if (strncmp(info.driver_name, "net_nfp", 6)) {
> +conf.rxmode.enable_scatter = 1;
> +}
> }
>
> conf.rxmode.hw_ip_checksum = (dev->hw_ol_features &
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] datapath-windows: Prevent ct-counters from getting redundantly incremented
> On 27 Apr 2018, at 20:00, Anand Kumar wrote:
>
> The conntrack-counters ought to be incremented only if it's a new lookup
> or if it's recirculated through a different zone for the first time.
>
> Signed-off-by: Anand Kumar
> ---
> datapath-windows/ovsext/Conntrack.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/datapath-windows/ovsext/Conntrack.c
> b/datapath-windows/ovsext/Conntrack.c
> index 678bedb..add1491 100644
> --- a/datapath-windows/ovsext/Conntrack.c
> +++ b/datapath-windows/ovsext/Conntrack.c
> @@ -886,10 +886,11 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
> return NDIS_STATUS_RESOURCES;
> }
>
> -/* Increment the counters soon after the lookup, since we set ct.state
> - * to OVS_CS_F_TRACKED after processing the ct entry.
> +/* Increment stats for the entry if it wasn't tracked previously or
> + * if they are on different zones
> */
> -if (entry && (!(key->ct.state & OVS_CS_F_TRACKED))) {
> +if (entry && (entry->key.zone != key->ct.zone ||
> + (!(key->ct.state & OVS_CS_F_TRACKED {
> OvsCtIncrementCounters(entry, ctx.reply, curNbl);
> }
>
> --
> 2.9.3.windows.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
Acked-by: Alin Gabriel Serdean mailto:aserd...@ovn.org>>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 00/11] Patches 1-11 of ERSPAN backport
On 4/25/2018 9:21 AM, Greg Rose wrote: This series of patches is the first half of the backport of the Linux kernel upstream ERSPAN feature support. The first patch does some cleanup of unsupported kernel code. The remaining patches in the series begin the backport of the actual ERSPAN code. As part of the ERSPAN backport it was necessary to fixup the current out of tree GRE and IP tunneling support by pulling in code from the upstream Linux kernel. There was a great deal of infrastructure missing so much of this patch series is actually devoted to making sure the proper IPV4 tunneling code is pulled in from the upstream kernel. Currently the series only builds on kernels <= 4.9. A future patch will enable builds on kernels greater than 4.9. Please ignore this patch series - we've fixed a few things so I will repost a V2 next week. Thanks, - Greg Greg Rose (1): compat: Remove unsupported kernel compat code William Tu (7): gre: introduce native tunnel support for ERSPAN gre: fix goto statement typo gre: refactor the gre_fb_xmit compat/gre: add collect_md mode ip_gre: check packet length and mtu correctly in erspan tx ip_gre: Refactor the erpsan tunnel code. compat/erspan: refactor existing erspan code Xin Long (3): ip_gre: get key from session_id correctly in erspan_rcv ip_gre: set tunnel hlen properly in erspan_tunnel_init ip_gre: erspan device should keep dst acinclude.m4 | 49 +- datapath/linux/Modules.mk |3 +- datapath/linux/compat/gre.c| 222 ++-- datapath/linux/compat/include/linux/etherdevice.h | 30 - datapath/linux/compat/include/linux/if_ether.h |4 + datapath/linux/compat/include/linux/if_vlan.h | 11 - datapath/linux/compat/include/linux/kconfig.h |8 - datapath/linux/compat/include/linux/kernel.h | 38 - .../linux/compat/include/linux/netdev_features.h | 19 - datapath/linux/compat/include/linux/netdevice.h|5 - datapath/linux/compat/include/linux/skbuff.h | 36 +- datapath/linux/compat/include/linux/workqueue.h|4 - datapath/linux/compat/include/net/checksum.h |6 - datapath/linux/compat/include/net/dst.h| 28 +- datapath/linux/compat/include/net/dst_metadata.h | 23 +- datapath/linux/compat/include/net/erspan.h | 116 ++ datapath/linux/compat/include/net/genetlink.h | 11 - datapath/linux/compat/include/net/gre.h| 13 +- datapath/linux/compat/include/net/ip6_route.h | 23 - datapath/linux/compat/include/net/ip_tunnels.h | 226 +++- datapath/linux/compat/include/net/ipv6.h | 15 - .../include/net/netfilter/nf_conntrack_zones.h |2 - datapath/linux/compat/include/net/netlink.h| 15 - datapath/linux/compat/include/net/route.h | 105 -- datapath/linux/compat/ip_gre.c | 1103 ++-- datapath/linux/compat/ip_tunnel.c | 501 - datapath/linux/compat/ip_tunnels_core.c| 41 + datapath/linux/compat/lisp.c |2 - datapath/linux/compat/stt.c|6 - datapath/linux/compat/udp_tunnel.c |2 - datapath/linux/compat/utils.c | 22 - 31 files changed, 2046 insertions(+), 643 deletions(-) create mode 100644 datapath/linux/compat/include/net/erspan.h ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2] datapath-windows: Prevent ct-counters from getting redundantly incremented
The conntrack-counters ought to be incremented only if it's a new lookup
or if it's recirculated through a different zone for the first time.
Signed-off-by: Anand Kumar
---
datapath-windows/ovsext/Conntrack.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/datapath-windows/ovsext/Conntrack.c
b/datapath-windows/ovsext/Conntrack.c
index 678bedb..add1491 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -886,10 +886,11 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
return NDIS_STATUS_RESOURCES;
}
-/* Increment the counters soon after the lookup, since we set ct.state
- * to OVS_CS_F_TRACKED after processing the ct entry.
+/* Increment stats for the entry if it wasn't tracked previously or
+ * if they are on different zones
*/
-if (entry && (!(key->ct.state & OVS_CS_F_TRACKED))) {
+if (entry && (entry->key.zone != key->ct.zone ||
+ (!(key->ct.state & OVS_CS_F_TRACKED {
OvsCtIncrementCounters(entry, ctx.reply, curNbl);
}
--
2.9.3.windows.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] datapath-windows: Update ct stats when packet is processed by conntrack
Hi Sairam,
Sure. Will update the commit message and send out V2.
Thanks,
Anand Kumar
On 4/26/18, 3:57 PM, "Sairam Venugopal" wrote:
Anand,
Thanks for the patch. Can you update the commit message to better describe
the underlying issue?
Prevent conntrack-counters from getting redundantly incremented for
recirculated packets.
The counters ought to be incremented only if it's a new lookup or if it's
recirculated through a different zone for the first time.
Thanks,
Sairam
On 4/25/18, 1:06 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand
Kumar"
wrote:
When ct lookup returns a matching ct entry, increment ct stats
even if the zone information in conntrack entry does not match with
flowkey.
Signed-off-by: Anand Kumar
---
datapath-windows/ovsext/Conntrack.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/datapath-windows/ovsext/Conntrack.c
b/datapath-windows/ovsext/Conntrack.c
index 678bedb..add1491 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -886,10 +886,11 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
return NDIS_STATUS_RESOURCES;
}
-/* Increment the counters soon after the lookup, since we set
ct.state
- * to OVS_CS_F_TRACKED after processing the ct entry.
+/* Increment stats for the entry if it wasn't tracked previously or
+ * if they are on different zones
*/
-if (entry && (!(key->ct.state & OVS_CS_F_TRACKED))) {
+if (entry && (entry->key.zone != key->ct.zone ||
+ (!(key->ct.state & OVS_CS_F_TRACKED {
OvsCtIncrementCounters(entry, ctx.reply, curNbl);
}
--
2.9.3.windows.1
___
dev mailing list
d...@openvswitch.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=0j1dB0xbZjupscaOcQmDzLRgDPo5kjVp8k_-HX4w7P8&s=HdqtDC96bCuR7w2P7qVPA5skEcXSEeVqVbqefbaA5pw&e=
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v4 1/1] netdev-dpdk: don't enable scatter for jumbo RX support for nfp
Currently to RX jumbo packets fails for NICs not supporting scatter.
Scatter is not strictly needed for jumbo RX support. This change fixes
the issue by not enabling scatter only for the PMD/NIC known not to
need it to support jumbo RX.
Note: this change is temporary and not needed for later releases OVS/DPDK
Reported-by: Louis Peens
Signed-off-by: Pablo Cascón
Reviewed-by: Simon Horman
---
lib/netdev-dpdk.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index ee39cbe..fdc8f66 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -694,11 +694,19 @@ dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev, int
n_rxq, int n_txq)
int diag = 0;
int i;
struct rte_eth_conf conf = port_conf;
+struct rte_eth_dev_info info;
-/* For some NICs (e.g. Niantic), scatter_rx mode needs to be explicitly
- * enabled. */
+/* As of DPDK 17.11.1 a few PMDs require to explicitly enable
+ * scatter to support jumbo RX. Checking the offload capabilities
+ * is not an option as PMDs are not required yet to report
+ * them. The only reliable info is the driver name and knowledge
+ * (testing or code review). Listing all such PMDs feels harder
+ * than highlighting the one known not to need scatter */
if (dev->mtu > ETHER_MTU) {
-conf.rxmode.enable_scatter = 1;
+rte_eth_dev_info_get(dev->port_id, &info);
+if (strncmp(info.driver_name, "net_nfp", 6)) {
+conf.rxmode.enable_scatter = 1;
+}
}
conf.rxmode.hw_ip_checksum = (dev->hw_ol_features &
--
2.7.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/1] netdev-dpdk: Fixed netdev_dpdk structure alignment
Thanks for this, Eelco.
(Sorry for the double email, missed the ML on the first one.)
On 25/04/2018 16:48, Eelco Chaudron wrote:
Currently, the code tells us we have 4 pad bytes left in cacheline0
while actually we are 8 bytes short:
This was caused by commit 5e925cc ("netdev-dpdk: DPDK v17.11 upgrade"),
where the dpdk_port_t typedef was changed from uint8_t to uint16_t,
messing up the alignment.
struct netdev_dpdk {
union {
OVS_CACHE_LINE_MARKER cacheline0;/* 1 */
struct {
dpdk_port_t port_id; /* 0 2 */
_Bool attached; /* 2 1 */
struct eth_addr hwaddr; /* 4 6 */
intmtu; /*12 4 */
intsocket_id;/*16 4 */
intbuf_size; /*20 4 */
intmax_packet_len; /*24 4 */
enum dpdk_dev_type type; /*28 4 */
enum netdev_flags flags; /*32 4 */
char * devargs; /*40 8 */
struct dpdk_tx_queue * tx_q; /*48 8 */
struct rte_eth_link link;/*56 8 */
intlink_reset_cnt; /*64 4 */
}; /* 72 */
uint8_tpad9[128];/* 128 */
}; /* 0 128 */
/* --- cacheline 2 boundary (128 bytes) --- */
Re-located one member, link_reset_cnt, and now it's one cache line:
struct netdev_dpdk {
union {
OVS_CACHE_LINE_MARKER cacheline0;/* 1 */
struct {
dpdk_port_t port_id; /* 0 2 */
_Bool attached; /* 2 1 */
struct eth_addr hwaddr; /* 4 6 */
intmtu; /*12 4 */
intsocket_id;/*16 4 */
intbuf_size; /*20 4 */
intmax_packet_len; /*24 4 */
enum dpdk_dev_type type; /*28 4 */
enum netdev_flags flags; /*32 4 */
intlink_reset_cnt; /*36 4 */
char * devargs; /*40 8 */
struct dpdk_tx_queue * tx_q; /*48 8 */
struct rte_eth_link link;/*56 8 */
}; /* 64 */
uint8_tpad9[64]; /* 64 */
}; /* 064 */
/* --- cacheline 1 boundary (64 bytes) --- */
Signed-off-by: Eelco Chaudron
Acked-by: Tiago Lam
Tiago
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] Documentation: Fix binary representation of 80 and 8080 in Faucet tutorial
On 2018-04-26 15:39, a...@tripier.fr wrote: > The binary representation of 80 and 8080 are switched in the Faucet tutorial. > > Signed-off-by: Axel Tripier > --- > Documentation/tutorials/faucet.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Please disregard this patch (bad formatting), I have sent a new one correctly formatted here: https://patchwork.ozlabs.org/patch/905792/ Axel Tripier ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Doc: Fix binary representation in Faucet tutorial
The binary representation of 80 and 8080 are switched in the Faucet tutorial. Signed-off-by: Axel Tripier --- Documentation/tutorials/faucet.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/tutorials/faucet.rst b/Documentation/tutorials/faucet.rst index 9abfa6ebd..aaaffe769 100644 --- a/Documentation/tutorials/faucet.rst +++ b/Documentation/tutorials/faucet.rst @@ -1383,8 +1383,8 @@ Take a look at the Megaflow line and in particular the match on the megaflow matches on only the top 4 bits of the TCP destination port. That works because:: -80 (base 10) == 0001,,1001, (base 2) - 8080 (base 10) == ,,0101, (base 2) +80 (base 10) == ,,0101, (base 2) + 8080 (base 10) == 0001,,1001, (base 2) and so by matching on only the top 4 bits, rather than all 16, the OVS fast path can distinguish port 80 from port 8080. This allows this -- 2.17.0 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] Documentation: Fix commands not being shown in code blocks
On 2018-04-27 16:12, a...@tripier.fr wrote: > Some commands are not shown in code blocks in the Advances Features > tutorial, they are shown as variable width text because of a missing ":" > to designate them as code blocks. > > Signed-off-by: Axel Tripier > --- > Documentation/tutorials/ovs-advanced.rst | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Please disregard this patch (bad formatting), I have sent a new one correctly formatted here: https://patchwork.ozlabs.org/patch/905776/ Axel Tripier ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] Doc: Fix commands not being shown in code blocks
Some commands are not shown in code blocks in the Advances Features tutorial, they are shown as variable width text because of a missing ":" to designate them as code blocks. Signed-off-by: Axel Tripier --- Documentation/tutorials/ovs-advanced.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/tutorials/ovs-advanced.rst b/Documentation/tutorials/ovs-advanced.rst index 676137f3c..c0784db04 100644 --- a/Documentation/tutorials/ovs-advanced.rst +++ b/Documentation/tutorials/ovs-advanced.rst @@ -726,7 +726,7 @@ which ought to show roughly the following, with extraneous details removed:: The other way is to inject a packet to take advantage of the learning entry. For example, we can inject a packet on p2 whose destination is the MAC address -that we just learned on p1: +that we just learned on p1:: $ ovs-appctl ofproto/trace br0 \ in_port=2,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01 -generate @@ -763,7 +763,7 @@ the learned port ``p1`` into register ``0``:: If you read the commands above carefully, then you might have noticed that they simply have the Ethernet source and destination addresses exchanged. That -means that if we now rerun the first ``ovs-appctl`` command above, e.g.: +means that if we now rerun the first ``ovs-appctl`` command above, e.g.:: $ ovs-appctl ofproto/trace br0 \ in_port=1,dl_vlan=20,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01 \ @@ -926,7 +926,7 @@ Now, if we rerun our first command:: -generate ...we can see that the result is no longer a flood but to the specified learned -destination port ``p4``: +destination port ``p4``:: Datapath actions: pop_vlan,4 -- 2.17.0 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Gerentes y Supervisores - En Línea
Administración Efectica del tiempo para GERENTES o SUPERVISORES. Fecha: 17/Mayo/2018 Horario: 10:00 a 13:00 y 15:00 a 18:00 horas "Elimine para siempre la frase “No nos alcanza el tiempo” " En este seminario online en vivo aprenderá: Aprenda a planificar y organizar. 10 Soluciones para el control. Tiempos y movimientos. Medición de la efectividad. Cómo controlar verdaderamente la jornada laboral. Responda este correo con el asunto Gerentes, con los siguientes datos: Nombre: Correo: Teléfono: Si lo que usted desea dejar de recibir este tipo de mensajes responder este correo con el asunto BAJA ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] Documentation: Fix commands not being shown in code blocks
Some commands are not shown in code blocks in the Advances Features tutorial, they are shown as variable width text because of a missing ":" to designate them as code blocks. Signed-off-by: Axel Tripier --- Documentation/tutorials/ovs-advanced.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/tutorials/ovs-advanced.rst b/Documentation/tutorials/ovs-advanced.rst index 676137f3c..c0784db04 100644 --- a/Documentation/tutorials/ovs-advanced.rst +++ b/Documentation/tutorials/ovs-advanced.rst @@ -726,7 +726,7 @@ which ought to show roughly the following, with extraneous details removed:: The other way is to inject a packet to take advantage of the learning entry. For example, we can inject a packet on p2 whose destination is the MAC address -that we just learned on p1: +that we just learned on p1:: $ ovs-appctl ofproto/trace br0 \ in_port=2,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01 -generate @@ -763,7 +763,7 @@ the learned port ``p1`` into register ``0``:: If you read the commands above carefully, then you might have noticed that they simply have the Ethernet source and destination addresses exchanged. That -means that if we now rerun the first ``ovs-appctl`` command above, e.g.: +means that if we now rerun the first ``ovs-appctl`` command above, e.g.:: $ ovs-appctl ofproto/trace br0 \ in_port=1,dl_vlan=20,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01 \ @@ -926,7 +926,7 @@ Now, if we rerun our first command:: -generate ...we can see that the result is no longer a flood but to the specified learned -destination port ``p4``: +destination port ``p4``:: Datapath actions: pop_vlan,4 -- 2.17.0 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v3 3/3] ofproto-dpif: Use dp_hash as default selection method
The dp_hash selection method for select groups overcomes the scalability
problems of the current default selection method which, due to L2-L4
hashing during xlation and un-wildcarding of the hashed fields,
basically requires an upcall to the slow path to load-balance every
L4 connection. The consequence are an explosion of datapath flows
(megaflows degenerate to miniflows) and a limitation of connection
setup rate OVS can handle.
This commit changes the default selection method to dp_hash, provided the
bucket configuration is such that the dp_hash method can accurately
represent the bucket weights with up to 64 hash values. Otherwise we
stick to original default hash method.
We use the new dp_hash algorithm OVS_HASH_L4_SYMMETRIC to maintain the
symmetry property of the old default hash method.
A controller can explicitly request the old default hash selection method
by specifying selection method "hash" with an empty list of fields in the
Group properties of the OpenFlow 1.5 Group Mod message.
Update the documentation about selection method in the ovs-ovctl man page.
Revise and complete the ofproto-dpif unit tests cases for select groups.
Signed-off-by: Jan Scheurich
Signed-off-by: Nitin Katiyar
Co-authored-by: Nitin Katiyar
---
NEWS | 2 +
lib/ofp-group.c| 15 ++-
ofproto/ofproto-dpif.c | 30 +++--
ofproto/ofproto-dpif.h | 1 +
ofproto/ofproto-provider.h | 2 +-
tests/mpls-xlate.at| 26 ++--
tests/ofproto-dpif.at | 315 +++--
tests/ofproto-macros.at| 7 +-
utilities/ovs-ofctl.8.in | 47 ---
9 files changed, 334 insertions(+), 111 deletions(-)
diff --git a/NEWS b/NEWS
index cd4ffbb..fbd987f 100644
--- a/NEWS
+++ b/NEWS
@@ -15,6 +15,8 @@ Post-v2.9.0
- ovs-vsctl: New commands "add-bond-iface" and "del-bond-iface".
- OpenFlow:
* OFPT_ROLE_STATUS is now available in OpenFlow 1.3.
+ * Default selection method for select groups is now dp_hash with improved
+ accuracy.
- Linux kernel 4.14
* Add support for compiling OVS with the latest Linux 4.14 kernel
- ovn:
diff --git a/lib/ofp-group.c b/lib/ofp-group.c
index 31b0437..c5ddc65 100644
--- a/lib/ofp-group.c
+++ b/lib/ofp-group.c
@@ -1518,12 +1518,17 @@ parse_group_prop_ntr_selection_method(struct ofpbuf
*payload,
return OFPERR_OFPBPC_BAD_VALUE;
}
-error = oxm_pull_field_array(payload->data, fields_len,
- &gp->fields);
-if (error) {
-OFPPROP_LOG(&rl, false,
+if (fields_len > 0) {
+error = oxm_pull_field_array(payload->data, fields_len,
+&gp->fields);
+if (error) {
+OFPPROP_LOG(&rl, false,
"ntr selection method fields are invalid");
-return error;
+return error;
+}
+} else {
+/* Selection_method "hash: w/o fields means default hash method. */
+gp->fields.values_size = 0;
}
return 0;
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index f5ecd8b..52282a8 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -1,5 +1,4 @@
/*
- * Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017 Nicira,
Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -4787,7 +4786,7 @@ group_setup_dp_hash_table(struct group_dpif *group,
size_t max_hash)
} *webster;
if (n_buckets == 0) {
-VLOG_DBG(" Don't apply dp_hash method without buckets");
+VLOG_DBG(" Don't apply dp_hash method without buckets.");
return false;
}
@@ -4860,9 +4859,24 @@ group_set_selection_method(struct group_dpif *group)
const struct ofputil_group_props *props = &group->up.props;
const char *selection_method = props->selection_method;
+VLOG_DBG("Constructing select group %"PRIu32, group->up.group_id);
if (selection_method[0] == '\0') {
-VLOG_DBG("No selection method specified.");
-group->selection_method = SEL_METHOD_DEFAULT;
+VLOG_DBG("No selection method specified. Trying dp_hash.");
+/* If the controller has not specified a selection method, check if
+ * the dp_hash selection method with max 64 hash values is appropriate
+ * for the given bucket configuration. */
+if (group_setup_dp_hash_table(group, 64)) {
+/* Use dp_hash selection method with symmetric L4 hash. */
+group->selection_method = SEL_METHOD_DP_HASH;
+group->hash_alg = OVS_HASH_ALG_SYM_L4;
+group->hash_basis = 0;
+VLOG_DBG("Use dp_hash with %d hash values using algorithm %d.",
+ group->hash_mask + 1, group->hash_alg);
+} else {
+/* Fall back to original default hashing in slow path. */
+VLOG_DBG("Falling back to default hash method.");
+
[ovs-dev] [PATCH v3 1/3] userspace datapath: Add OVS_HASH_L4_SYMMETRIC dp_hash algorithm
This commit implements a new dp_hash algorithm OVS_HASH_L4_SYMMETRIC in
the netdev datapath. It will be used as default hash algorithm for the
dp_hash-based select groups in a subsequent commit to maintain
compatibility with the symmetry property of the current default hash
selection method.
A new dpif_backer_support field 'max_hash_alg' is introduced to reflect
the highest hash algorithm a datapath supports in the dp_hash action.
Signed-off-by: Jan Scheurich
Signed-off-by: Nitin Katiyar
Co-authored-by: Nitin Katiyar
---
datapath/linux/compat/include/linux/openvswitch.h | 4 ++
lib/flow.c| 43 +-
lib/flow.h| 1 +
lib/odp-execute.c | 23 ++--
ofproto/ofproto-dpif-xlate.c | 7 +++-
ofproto/ofproto-dpif.c| 45 +++
ofproto/ofproto-dpif.h| 5 ++-
7 files changed, 121 insertions(+), 7 deletions(-)
diff --git a/datapath/linux/compat/include/linux/openvswitch.h
b/datapath/linux/compat/include/linux/openvswitch.h
index 84ebcaf..2bb3cb2 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -720,6 +720,10 @@ struct ovs_action_push_vlan {
*/
enum ovs_hash_alg {
OVS_HASH_ALG_L4,
+#ifndef __KERNEL__
+ OVS_HASH_ALG_SYM_L4,
+#endif
+ __OVS_HASH_MAX
};
/*
diff --git a/lib/flow.c b/lib/flow.c
index 09b66b8..c65b288 100644
--- a/lib/flow.c
+++ b/lib/flow.c
@@ -2108,6 +2108,45 @@ flow_hash_symmetric_l4(const struct flow *flow, uint32_t
basis)
return jhash_bytes(&fields, sizeof fields, basis);
}
+/* Symmetrically Hashes non-IP 'flow' based on its L2 headers. */
+uint32_t
+flow_hash_symmetric_l2(const struct flow *flow, uint32_t basis)
+{
+union {
+struct {
+ovs_be16 eth_type;
+ovs_be16 vlan_tci;
+struct eth_addr eth_addr;
+ovs_be16 pad;
+};
+uint32_t word[3];
+} fields;
+
+uint32_t hash = basis;
+int i;
+
+if (flow->packet_type != htonl(PT_ETH)) {
+/* Cannot hash non-Ethernet flows */
+return 0;
+}
+
+for (i = 0; i < ARRAY_SIZE(fields.eth_addr.be16); i++) {
+fields.eth_addr.be16[i] =
+flow->dl_src.be16[i] ^ flow->dl_dst.be16[i];
+}
+fields.vlan_tci = 0;
+for (i = 0; i < FLOW_MAX_VLAN_HEADERS; i++) {
+fields.vlan_tci ^= flow->vlans[i].tci & htons(VLAN_VID_MASK);
+}
+fields.eth_type = flow->dl_type;
+fields.pad = 0;
+
+hash = hash_add(hash, fields.word[0]);
+hash = hash_add(hash, fields.word[1]);
+hash = hash_add(hash, fields.word[2]);
+return hash_finish(hash, basis);
+}
+
/* Hashes 'flow' based on its L3 through L4 protocol information */
uint32_t
flow_hash_symmetric_l3l4(const struct flow *flow, uint32_t basis,
@@ -2128,8 +2167,8 @@ flow_hash_symmetric_l3l4(const struct flow *flow,
uint32_t basis,
hash = hash_add64(hash, a[i] ^ b[i]);
}
} else {
-/* Cannot hash non-IP flows */
-return 0;
+/* Revert to hashing L2 headers */
+return flow_hash_symmetric_l2(flow, basis);
}
hash = hash_add(hash, flow->nw_proto);
diff --git a/lib/flow.h b/lib/flow.h
index af82931..900e8f8 100644
--- a/lib/flow.h
+++ b/lib/flow.h
@@ -236,6 +236,7 @@ hash_odp_port(odp_port_t odp_port)
uint32_t flow_hash_5tuple(const struct flow *flow, uint32_t basis);
uint32_t flow_hash_symmetric_l4(const struct flow *flow, uint32_t basis);
+uint32_t flow_hash_symmetric_l2(const struct flow *flow, uint32_t basis);
uint32_t flow_hash_symmetric_l3l4(const struct flow *flow, uint32_t basis,
bool inc_udp_ports );
diff --git a/lib/odp-execute.c b/lib/odp-execute.c
index 1969f02..c716c41 100644
--- a/lib/odp-execute.c
+++ b/lib/odp-execute.c
@@ -726,14 +726,16 @@ odp_execute_actions(void *dp, struct dp_packet_batch
*batch, bool steal,
}
switch ((enum ovs_action_attr) type) {
+
case OVS_ACTION_ATTR_HASH: {
const struct ovs_action_hash *hash_act = nl_attr_get(a);
-/* Calculate a hash value directly. This might not match the
+/* Calculate a hash value directly. This might not match the
* value computed by the datapath, but it is much less expensive,
* and the current use case (bonding) does not require a strict
* match to work properly. */
-if (hash_act->hash_alg == OVS_HASH_ALG_L4) {
+switch (hash_act->hash_alg) {
+case OVS_HASH_ALG_L4: {
struct flow flow;
uint32_t hash;
@@ -749,7 +751,22 @@ odp_execute_actions(void *dp, struct dp_packet_batch
*batch, bool steal,
}
packet->md.dp_hash = hash;
}
-
[ovs-dev] [PATCH v3 0/3] Use improved dp_hash select group by default
The current default OpenFlow select group implementation sends every new L4 flow to the slow path for the balancing decision and installs a 5-tuple "miniflow" in the datapath to forward subsequent packets of the connection accordingly. Clearly this has major scalability issues with many parallel L4 flows and high connection setup rates. The dp_hash selection method for the OpenFlow select group was added to OVS as an alternative. It avoids the scalability issues for the price of an additional recirculation in the datapath. The dp_hash method is only available to OF1.5 SDN controllers speaking the Netronome Group Mod extension to configure the selection mechanism. This severely limited the applicability of the dp_hash select group in the past. Furthermore, testing revealed that the implemented dp_hash selection often generated a very uneven distribution of flows over group buckets and didn't consider bucket weights at all. The present patch set in a first step improves the dp_hash selection method to much more accurately distribute flows over weighted group buckets and to apply a symmetric dp_hash function to maintain the symmetry property of the legacy hash function. In a second step it makes the improved dp_hash method the default in OVS for select groups that can be accurately handled by dp_hash. That should be the vast majority of cases. Otherwise we fall back to the legacy slow-path selection method. The Netronome extension can still be used to override the default decision and require the legacy slow-path or the dp_hash selection method. v2 -> v3: - Fixed another corner case crash reported by Chen Yuefang. - Fixed several sparse and clang warnings reported by Ben. - Rewritten the select group unit tests to abstract the checks from the behavior of the system-specific hash function implementation. - Added dpif_backer_support field for dp_hash algorithms to prevent using the new OVS_HASH_L4_SYMMETRIC algorithm if it is not supported by the datapath. v1 -> v2: - Fixed crashes for corner cases reported by Chen Yuefang. - Fixed group ref leakage with dp_hash reported by Chen Yuefang. - Changed all xlation logging from INFO to DBG. - Revised, completed and detailed select group unit test cases in ofproto-dpif. - Updated selection_method documentation in ovs-ofctl man page. - Added NEWS item. Jan Scheurich (3): userspace datapath: Add OVS_HASH_L4_SYMMETRIC dp_hash algorithm ofproto-dpif: Improve dp_hash selection method for select groups ofproto-dpif: Use dp_hash as default selection method NEWS | 2 + datapath/linux/compat/include/linux/openvswitch.h | 4 + include/openvswitch/ofp-group.h | 1 + lib/flow.c| 43 ++- lib/flow.h| 1 + lib/odp-execute.c | 23 +- lib/odp-util.c| 4 +- lib/ofp-group.c | 15 +- ofproto/ofproto-dpif-xlate.c | 89 -- ofproto/ofproto-dpif.c| 209 +- ofproto/ofproto-dpif.h| 19 +- ofproto/ofproto-provider.h| 2 +- tests/mpls-xlate.at | 26 +- tests/ofproto-dpif.at | 314 +- tests/ofproto-macros.at | 7 +- utilities/ovs-ofctl.8.in | 47 ++-- 16 files changed, 667 insertions(+), 139 deletions(-) -- 1.9.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v3 2/3] ofproto-dpif: Improve dp_hash selection method for select groups
The current implementation of the "dp_hash" selection method suffers
from two deficiences: 1. The hash mask and hence the number of dp_hash
values is just large enough to cover the number of group buckets, but
does not consider the case that buckets have different weights. 2. The
xlate-time selection of best bucket from the masked dp_hash value often
results in bucket load distributions that are quite different from the
bucket weights because the number of available masked dp_hash values
is too small (2-6 bits compared to 32 bits of a full hash in the default
hash selection method).
This commit provides a more accurate implementation of the dp_hash
select group by applying the well known Webster method for distributing
a small number of "seats" fairly over the weighted "parties"
(see https://en.wikipedia.org/wiki/Webster/Sainte-Lagu%C3%AB_method).
The dp_hash mask is autmatically chosen large enough to provide good
enough accuracy even with widely differing weights.
This distribution happens at group modification time and the resulting
table is stored with the group-dpif struct. At xlation time, we use the
masked dp_hash values as index to look up the assigned bucket.
If the bucket should not be live, we do a circular search over the
mapping table until we find the first live bucket. As the buckets in
the table are by construction in pseudo-random order with a frequency
according to their weight, this method maintains correct distribution
even if one or more buckets are non-live.
Xlation is further simplified by storing some derived select group state
at group construction in struct group-dpif in a form better suited for
xlation purposes.
Adapted the unit test case for dp_hash select group accordingly.
Signed-off-by: Jan Scheurich
Signed-off-by: Nitin Katiyar
Co-authored-by: Nitin Katiyar
---
include/openvswitch/ofp-group.h | 1 +
lib/odp-util.c | 4 +-
ofproto/ofproto-dpif-xlate.c| 82 ++
ofproto/ofproto-dpif.c | 148
ofproto/ofproto-dpif.h | 13
tests/ofproto-dpif.at | 15 ++--
6 files changed, 227 insertions(+), 36 deletions(-)
diff --git a/include/openvswitch/ofp-group.h b/include/openvswitch/ofp-group.h
index 8d893a5..af4033d 100644
--- a/include/openvswitch/ofp-group.h
+++ b/include/openvswitch/ofp-group.h
@@ -47,6 +47,7 @@ struct bucket_counter {
/* Bucket for use in groups. */
struct ofputil_bucket {
struct ovs_list list_node;
+uint16_t aux; /* Padding. Also used for temporary data. */
uint16_t weight;/* Relative weight, for "select" groups. */
ofp_port_t watch_port; /* Port whose state affects whether this bucket
* is live. Only required for fast failover
diff --git a/lib/odp-util.c b/lib/odp-util.c
index 6db241a..2db4e9d 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -595,7 +595,9 @@ format_odp_hash_action(struct ds *ds, const struct
ovs_action_hash *hash_act)
ds_put_format(ds, "hash(");
if (hash_act->hash_alg == OVS_HASH_ALG_L4) {
-ds_put_format(ds, "hash_l4(%"PRIu32")", hash_act->hash_basis);
+ds_put_format(ds, "l4(%"PRIu32")", hash_act->hash_basis);
+} else if (hash_act->hash_alg == OVS_HASH_ALG_SYM_L4) {
+ds_put_format(ds, "sym_l4(%"PRIu32")", hash_act->hash_basis);
} else {
ds_put_format(ds, "Unknown hash algorithm(%"PRIu32")",
hash_act->hash_alg);
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 05db090..e6d97a4 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -4380,35 +4380,59 @@ xlate_hash_fields_select_group(struct xlate_ctx *ctx,
struct group_dpif *group,
}
}
+static struct ofputil_bucket *
+group_dp_hash_best_bucket(struct xlate_ctx *ctx,
+ const struct group_dpif *group,
+ uint32_t dp_hash)
+{
+struct ofputil_bucket *bucket, *best_bucket = NULL;
+uint32_t n_hash = group->hash_mask + 1;
+
+uint32_t hash = dp_hash &= group->hash_mask;
+ctx->wc->masks.dp_hash |= group->hash_mask;
+
+/* Starting from the original masked dp_hash value iterate over the
+ * hash mapping table to find the first live bucket. As the buckets
+ * are quasi-randomly spread over the hash values, this maintains
+ * a distribution according to bucket weights even when some buckets
+ * are non-live. */
+for (int i = 0; i < n_hash; i++) {
+bucket = group->hash_map[(hash + i) % n_hash];
+if (bucket_is_alive(ctx, bucket, 0)) {
+best_bucket = bucket;
+break;
+}
+}
+
+return best_bucket;
+}
+
static void
xlate_dp_hash_select_group(struct xlate_ctx *ctx, struct group_dpif *group,
bool is_last_action)
{
-struct ofputil_bucket *bucket;
-
/* dp_hash value 0 is special since it me
[ovs-dev] What are Key Performance Indicator's in ovs !
Hello Team, I am using Core Network Emulator() which uses ovs services to simulate the wired networks . My question is below 1. What are the Key Performance Indicator provided by *OVS *. 2. Any output files got generated which gives you the simulation results like 3. E2E Latency 4. Queue size(min,max,median), 5.Load on Links 6.Time to establish a stream 7. How much packets lost 8. Path information in case of network look Waiting for the valuable suggestions Team !!! Regards Rakesh Kumar ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] What are Key Performance Indicator's in ovs !
Hello Team, I am using Core Network Emulator() which uses ovs services to simulate the wired networks . My question is below 1. What are the Key Performance Indicator provided by OVS . 2. Any output files got generated which gives you the simulation results like 1. E2E Latency 2. Queue size(min,max,median), 3.Load on Links 4.Time to establish a stream 5. How much packets lost 6. Path information in case of network look Waiting for the valuable suggestions Team !!! Regards Rakesh Kumar ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 1/1] netdev-dpdk: remove enabling scatter for jumbo RX support
> On 26/04/18 19:41, Stokes, Ian wrote:
> >> On 04/26/2018 04:26 PM, Stokes, Ian wrote:
> Currently to RX jumbo packets fails for NICs not supporting scatter.
> Scatter is not strictly needed for jumbo RX support. This change
> fixes the issue by only enabling scatter for NICs known to need it
> to support jumbo RX. Add a quirk for "igb" while the PMD is fixed.
>
> >>> Thanks for the v3 Pablo, comments inline.
> >>>
> Reported-by: Louis Peens
> Signed-off-by: Pablo Cascón
> Reviewed-by: Simon Horman
> ---
>
> Changelog:
> v3->v2:
> - only check for driver_name
> - tested with "nfp" and not with "igb"
>
>
> lib/netdev-dpdk.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index
> ee39cbe..02ed85b
> 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -694,11 +694,17 @@ dpdk_eth_dev_queue_setup(struct netdev_dpdk
> *dev, int n_rxq, int n_txq)
> int diag = 0;
> int i;
> struct rte_eth_conf conf = port_conf;
> +struct rte_eth_dev_info info;
>
> -/* For some NICs (e.g. Niantic), scatter_rx mode needs to be
> explicitly
> - * enabled. */
> +/* Quirk: as of DPDK 17.11.1 igb's PMD requires explicitly
> + * enabling scatter to support jumbo RX. Note: PMDs are not
> + * required to set the offload capabilities and so is not
> reliable
> + * info, only the driver_name is after testing the PMD/NIC */
> if (dev->mtu > ETHER_MTU) {
> -conf.rxmode.enable_scatter = 1;
> +rte_eth_dev_info_get(dev->port_id, &info);
> +if (!strcmp(info.driver_name, "igb")) {
> >>> For igb devices condition above will never hit, the driver name in
> >>> info
> >> will be reported as 'net_e1000_igb'.
> >>> I'm seeing a bit of a list growing for other drivers that support
> >>> the
> >> current behavior/requirement for scatter with Jumbo frames.
> >>> Through testing today I saw that Scatter must be set for ixgbe SRIOV
> >> functions also, "net_ixgbe_vf".
> >>> From code inspection em devices "net_e1000_em" would have to be
> >>> included
> >> also.
> >>> I would think that 'net_e1000_igb_vf' will be required also when
> >>> set_mtu
> >> support is introduced in the future (quite likely), but for the
> >> moment that’s not relevant.
> >>> I'm wondering if there's an alternative solution to checking driver
> >> names as we could end up with an extensive list. Would have to look
> >> at this.
> >> Did I hear someone say "alternative solution"? ;-)
> >>
> >> ---8<---
> >> That's why I think it's better to make the exception for "nfp" at
> present.
> >> It works for nfp, it works for Intel and it works for any other NICs
> >> that currently work.
> >>
> >> When OVS is updated to a future DPDK release where all the PMDs
> >> support setting/not setting this flag, then I agree any workaround
> >> should be made for NICs that are not properly reporting their status,
> or have quirks.
> >> ---8<---
> >>
> >> https://mail.openvswitch.org/pipermail/ovs-dev/2018-April/346256.html
> >>
> > +1
> >
> > I do think this is a simpler solution until we have the offload API
> fully supported in DPDK for the relevant devices.
>
> OK fine, reluctantly agree. Let me share a tested v4 that makes the
> exception for "nfp".
> >
> > @Pablo: Do you want the solution backported to previous OVS versions
> also? The "nfp" approach would be ok I think but as flagged in previous
> mail, listing igb, ixgbe etc would be a different story as the behavior of
> these changed between DPDK releases.
>
> Yes, backport would be good please. The behavior of "nfp" has not changed
> (scatter is not needed for jumbo across releases)
>
Thanks for your work on this Pablo, look forward to the v4.
Thanks
Ian
> >
> > Just something we should be aware of.
> >
> > Ian
> >
> >> Kevin.
> >>
> >>> Ian
> >>>
> +conf.rxmode.enable_scatter = 1;
> +}
> }
>
> conf.rxmode.hw_ip_checksum = (dev->hw_ol_features &
> --
> 2.7.4
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >>> ___
> >>> dev mailing list
> >>> d...@openvswitch.org
> >>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >>>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 1/1] netdev-dpdk: remove enabling scatter for jumbo RX support
On 26/04/18 19:41, Stokes, Ian wrote:
On 04/26/2018 04:26 PM, Stokes, Ian wrote:
Currently to RX jumbo packets fails for NICs not supporting scatter.
Scatter is not strictly needed for jumbo RX support. This change
fixes the issue by only enabling scatter for NICs known to need it to
support jumbo RX. Add a quirk for "igb" while the PMD is fixed.
Thanks for the v3 Pablo, comments inline.
Reported-by: Louis Peens
Signed-off-by: Pablo Cascón
Reviewed-by: Simon Horman
---
Changelog:
v3->v2:
- only check for driver_name
- tested with "nfp" and not with "igb"
lib/netdev-dpdk.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index
ee39cbe..02ed85b
100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -694,11 +694,17 @@ dpdk_eth_dev_queue_setup(struct netdev_dpdk
*dev, int n_rxq, int n_txq)
int diag = 0;
int i;
struct rte_eth_conf conf = port_conf;
+struct rte_eth_dev_info info;
-/* For some NICs (e.g. Niantic), scatter_rx mode needs to be
explicitly
- * enabled. */
+/* Quirk: as of DPDK 17.11.1 igb's PMD requires explicitly
+ * enabling scatter to support jumbo RX. Note: PMDs are not
+ * required to set the offload capabilities and so is not reliable
+ * info, only the driver_name is after testing the PMD/NIC */
if (dev->mtu > ETHER_MTU) {
-conf.rxmode.enable_scatter = 1;
+rte_eth_dev_info_get(dev->port_id, &info);
+if (!strcmp(info.driver_name, "igb")) {
For igb devices condition above will never hit, the driver name in info
will be reported as 'net_e1000_igb'.
I'm seeing a bit of a list growing for other drivers that support the
current behavior/requirement for scatter with Jumbo frames.
Through testing today I saw that Scatter must be set for ixgbe SRIOV
functions also, "net_ixgbe_vf".
From code inspection em devices "net_e1000_em" would have to be included
also.
I would think that 'net_e1000_igb_vf' will be required also when set_mtu
support is introduced in the future (quite likely), but for the moment
that’s not relevant.
I'm wondering if there's an alternative solution to checking driver
names as we could end up with an extensive list. Would have to look at
this.
Did I hear someone say "alternative solution"? ;-)
---8<---
That's why I think it's better to make the exception for "nfp" at present.
It works for nfp, it works for Intel and it works for any other NICs that
currently work.
When OVS is updated to a future DPDK release where all the PMDs support
setting/not setting this flag, then I agree any workaround should be made
for NICs that are not properly reporting their status, or have quirks.
---8<---
https://mail.openvswitch.org/pipermail/ovs-dev/2018-April/346256.html
+1
I do think this is a simpler solution until we have the offload API fully
supported in DPDK for the relevant devices.
OK fine, reluctantly agree. Let me share a tested v4 that makes the
exception for "nfp".
@Pablo: Do you want the solution backported to previous OVS versions also? The
"nfp" approach would be ok I think but as flagged in previous mail, listing
igb, ixgbe etc would be a different story as the behavior of these changed between DPDK
releases.
Yes, backport would be good please. The behavior of "nfp" has not
changed (scatter is not needed for jumbo across releases)
Just something we should be aware of.
Ian
Kevin.
Ian
+conf.rxmode.enable_scatter = 1;
+}
}
conf.rxmode.hw_ip_checksum = (dev->hw_ol_features &
--
2.7.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1] Enhance conjunctive match support in OVN
On Fri, Apr 27, 2018 at 1:41 AM, Jakub Sitnicki wrote:
> Hi Numan,
>
> I've started reviewing your patch and it occurred to me that we can
> complicate
> the annotation a bit (but not much) and achieve the same effect. Please
> take a
> look at the proposed change [1].
>
> It seems to be passing your tests, with the changes as below:
>
> 1) I believe sets with just two items should also be considered a
> dimension,
>unless I'm reading ovs-fields man-page wrong.
>
> 2) It turns out we can apply conjunctive matching to the last "crazy"
> expression
>from your test as well. Quite surprising what the expression-to-matches
>converter spits out.
>
> Looking forward to hearing what you think about it.
>
That's great Jacub. I will try it out and let you know.
Thanks
Numan
>
> Thanks,
> Jakub
>
> [1] https://patchwork.ozlabs.org/patch/905334/
>
> ---8<---
>
> ---
> tests/ovn.at | 83 ++
> --
> 1 file changed, 58 insertions(+), 25 deletions(-)
>
> diff --git a/tests/ovn.at b/tests/ovn.at
> index 5f2c04c39..8fe4c522a 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -685,13 +685,13 @@ expr_to_flow () {
> lflow="ip4.src == {10.0.0.1, 10.0.0.2, 10.0.0.3} && \
> ip4.dst == {20.0.0.1, 20.0.0.2, 20.0.0.3}"
> AT_CHECK([expr_to_flow "$lflow"], [0], [dnl
> -conj_id=1
> -ip,nw_dst=20.0.0.1: conjunction(1, 1/2)
> -ip,nw_dst=20.0.0.2: conjunction(1, 1/2)
> -ip,nw_dst=20.0.0.3: conjunction(1, 1/2)
> -ip,nw_src=10.0.0.1: conjunction(1, 0/2)
> -ip,nw_src=10.0.0.2: conjunction(1, 0/2)
> -ip,nw_src=10.0.0.3: conjunction(1, 0/2)
> +conj_id=1,ip
> +ip,nw_dst=20.0.0.1: conjunction(1, 0/2)
> +ip,nw_dst=20.0.0.2: conjunction(1, 0/2)
> +ip,nw_dst=20.0.0.3: conjunction(1, 0/2)
> +ip,nw_src=10.0.0.1: conjunction(1, 1/2)
> +ip,nw_src=10.0.0.2: conjunction(1, 1/2)
> +ip,nw_src=10.0.0.3: conjunction(1, 1/2)
> ])
>
> lflow="ip && (!ct.est || (ct.est && ct_label.blocked == 1))"
> @@ -702,17 +702,15 @@ ct_state=-est+trk,ip
> ct_state=-est+trk,ipv6
> ])
>
> -# ip4.dst has only 2 items. So it shouldn't be considered as a
> -# dimension.
> lflow="ip4.src == {10.0.0.1, 10.0.0.2, 10.0.0.3} && \
> ip4.dst == {20.0.0.1, 20.0.0.2}"
> AT_CHECK([expr_to_flow "$lflow"], [0], [dnl
> -ip,nw_src=10.0.0.1,nw_dst=20.0.0.1
> -ip,nw_src=10.0.0.1,nw_dst=20.0.0.2
> -ip,nw_src=10.0.0.2,nw_dst=20.0.0.1
> -ip,nw_src=10.0.0.2,nw_dst=20.0.0.2
> -ip,nw_src=10.0.0.3,nw_dst=20.0.0.1
> -ip,nw_src=10.0.0.3,nw_dst=20.0.0.2
> +conj_id=1,ip
> +ip,nw_dst=20.0.0.1: conjunction(1, 0/2)
> +ip,nw_dst=20.0.0.2: conjunction(1, 0/2)
> +ip,nw_src=10.0.0.1: conjunction(1, 1/2)
> +ip,nw_src=10.0.0.2: conjunction(1, 1/2)
> +ip,nw_src=10.0.0.3: conjunction(1, 1/2)
> ])
>
> lflow="ip4 && ip4.src == {10.0.0.1, 10.0.0.2, 10.0.0.3} && \
> @@ -720,19 +718,19 @@ ip4.dst == {20.0.0.1, 20.0.0.2, 20.0.0.3} && \
> tcp.dst >= 1000 && tcp.dst <= 1010"
>
> AT_CHECK([expr_to_flow "$lflow"], [0], [dnl
> -conj_id=1
> -tcp,nw_dst=20.0.0.1: conjunction(1, 2/3)
> -tcp,nw_dst=20.0.0.2: conjunction(1, 2/3)
> -tcp,nw_dst=20.0.0.3: conjunction(1, 2/3)
> +conj_id=1,tcp
> +tcp,nw_dst=20.0.0.1: conjunction(1, 0/3)
> +tcp,nw_dst=20.0.0.2: conjunction(1, 0/3)
> +tcp,nw_dst=20.0.0.3: conjunction(1, 0/3)
> tcp,nw_src=10.0.0.1: conjunction(1, 1/3)
> tcp,nw_src=10.0.0.2: conjunction(1, 1/3)
> tcp,nw_src=10.0.0.3: conjunction(1, 1/3)
> -tcp,tp_dst=0x3ea/0xfffe: conjunction(1, 0/3)
> -tcp,tp_dst=0x3ec/0xfffc: conjunction(1, 0/3)
> -tcp,tp_dst=0x3f0/0xfffe: conjunction(1, 0/3)
> -tcp,tp_dst=1000: conjunction(1, 0/3)
> -tcp,tp_dst=1001: conjunction(1, 0/3)
> -tcp,tp_dst=1010: conjunction(1, 0/3)
> +tcp,tp_dst=0x3ea/0xfffe: conjunction(1, 2/3)
> +tcp,tp_dst=0x3ec/0xfffc: conjunction(1, 2/3)
> +tcp,tp_dst=0x3f0/0xfffe: conjunction(1, 2/3)
> +tcp,tp_dst=1000: conjunction(1, 2/3)
> +tcp,tp_dst=1001: conjunction(1, 2/3)
> +tcp,tp_dst=1010: conjunction(1, 2/3)
> ])
>
> lflow="ip4 && ip4.src == {10.0.0.4, 10.0.0.5, 10.0.0.6} && \
> @@ -741,6 +739,41 @@ tcp.dst <= 2000 && tcp.src >=1000 && tcp.src <= 2000)
> \
> || ip4.dst == 20.0.0.5 || ip4.dst == 20.0.0.6)"
>
> AT_CHECK([expr_to_flow "$lflow"], [0], [dnl
> +conj_id=1,tcp
> +ip,nw_src=10.0.0.4,nw_dst=20.0.0.5
> +ip,nw_src=10.0.0.4,nw_dst=20.0.0.6
> +ip,nw_src=10.0.0.5,nw_dst=20.0.0.5
> +ip,nw_src=10.0.0.5,nw_dst=20.0.0.6
> +ip,nw_src=10.0.0.6,nw_dst=20.0.0.5
> +ip,nw_src=10.0.0.6,nw_dst=20.0.0.6
> +tcp,nw_dst=20.0.0.4: conjunction(1, 0/4)
> +tcp,nw_dst=20.0.0.7: conjunction(1, 0/4)
> +tcp,nw_dst=20.0.0.8: conjunction(1, 0/4)
> +tcp,nw_src=10.0.0.4: conjunction(1, 1/4)
> +tcp,nw_src=10.0.0.5: conjunction(1, 1/4)
> +tcp,nw_src=10.0.0.6: conjunction(1, 1/4)
> +tcp,tp_dst=0x3ea/0xfffe: conjunction(1, 2/4)
> +tcp,tp_dst=0x3ec/0xfffc: conjunction(1, 2/4)
> +tcp,tp_dst=0x3f0/0xfff0: conjunction(1, 2/4)
> +tcp,tp_dst=0x400/0xfe00: conjunction(1, 2/4)
> +tcp,tp_dst=0x600/0xff00: conjunction(1, 2/4)
> +tcp,tp_dst=0x700/0xff80: conjunction(1, 2/4)
> +tcp,tp_dst=0x780/0xffc0: conjunction(1, 2/4)
>
Re: [ovs-dev] L0AN
Greetings, I offer flexible loans and funding for various projects by passing the usual rigorous procedures. This Funding program allows a client to enjoy low interest payback for as low as 3% per annul for a period of 1-20 years. I can approve a loan/funding for up to $500,000,000.00 or more depending on the nature of business. Contact us at: fastfundingd...@gmail.com Signed Management. Reply us at: fastfundingd...@gmail.com Please note: This message and any response to it may constitute a public record and thus be publicly available to anyone who requests it. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
