[ovs-dev] [PATCH v2] netdev: use acquire-release semantics for change_seq in netdev
"rxq_enabled" of netdev is writen in the vhost thread and read by pmd
thread once it observes 'change_seq' is updated. This patch is to keep
order on aarch64 or other weak memory model CPU to ensure 'rxq_enabled' is
observed before 'change_seq'.
Reviewed-by: Gavin Hu
Signed-off-by: Yanqin Wei
---
lib/netdev-provider.h | 13 +
lib/netdev.c | 7 ++-
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/lib/netdev-provider.h b/lib/netdev-provider.h
index 1e5a40c89..f109c4e66 100644
--- a/lib/netdev-provider.h
+++ b/lib/netdev-provider.h
@@ -63,7 +63,7 @@ struct netdev {
*
* Minimally, the sequence number is required to change whenever
* 'netdev''s flags, features, ethernet address, or carrier changes. */
-uint64_t change_seq;
+atomic_uint64_t change_seq;
/* A netdev provider might be unable to change some of the device's
* parameter (n_rxq, mtu) when the device is in use. In this case
@@ -91,12 +91,17 @@ struct netdev {
static inline void
netdev_change_seq_changed(const struct netdev *netdev_)
{
+uint64_t change_seq;
struct netdev *netdev = CONST_CAST(struct netdev *, netdev_);
seq_change(connectivity_seq_get());
-netdev->change_seq++;
-if (!netdev->change_seq) {
-netdev->change_seq++;
+
+atomic_read_relaxed(>change_seq, _seq);
+change_seq++;
+if (OVS_UNLIKELY(!change_seq)) {
+change_seq++;
}
+atomic_store_explicit(>change_seq, change_seq,
+ memory_order_release);
}
static inline void
diff --git a/lib/netdev.c b/lib/netdev.c
index af8f8560d..405c98c68 100644
--- a/lib/netdev.c
+++ b/lib/netdev.c
@@ -2039,7 +2039,12 @@ restore_all_flags(void *aux OVS_UNUSED)
uint64_t
netdev_get_change_seq(const struct netdev *netdev)
{
-return netdev->change_seq;
+uint64_t change_seq;
+
+atomic_read_explicit(_CAST(struct netdev *, netdev)->change_seq,
+_seq, memory_order_acquire);
+
+return change_seq;
}
#ifndef _WIN32
--
2.17.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1] netdev: use acquire-release semantics for change_seq in netdev
Hi Ben,
Thanks for your time to review. I am sorry not to verify this patch by clang
compiler. But this patch compiles successfully in gcc 7.4. Maybe in some gcc
version, the atomic type is necessary for atomic operation.
I will fix it in V2.
Best Regards,
Wei Yanqin
> -Original Message-
> From: Ben Pfaff
> Sent: Tuesday, November 26, 2019 5:54 AM
> To: Yanqin Wei (Arm Technology China)
> Cc: d...@openvswitch.org; ovs-dev@openvswitch.org; nd ;
> Gavin Hu (Arm Technology China)
> Subject: Re: [ovs-dev] [PATCH v1] netdev: use acquire-release semantics for
> change_seq in netdev
>
> On Mon, Nov 18, 2019 at 10:46:59AM +0800, Yanqin Wei wrote:
> > "rxq_enabled" of netdev is writen in the vhost thread and read by pmd
> > thread once it observes 'change_seq' is updated. This patch is to keep
> > order on aarch64 or other weak memory model CPU to ensure
> > 'rxq_enabled' is observed before 'change_seq'.
> >
> > Reviewed-by: Gavin Hu
> > Signed-off-by: Yanqin Wei
>
> Thanks for the patch.
>
> This does not compile. Clang says:
>
> In file included from ../lib/dpif-netdev.c:54:
> ../lib/netdev-provider.h:97:5: error: address argument to atomic operation
> must be a pointer to _Atomic type ('uint64_t *' (aka 'unsigned long *')
> invalid)
> ../lib/ovs-atomic-clang.h:82:16: note: expanded from macro
> 'atomic_add_explicit'
> In file included from ../lib/dpif-netdev.c:54:
> ../lib/netdev-provider.h:99:9: error: address argument to atomic operation
> must be a pointer to _Atomic type ('uint64_t *' (aka 'unsigned long *')
> invalid)
> ../lib/ovs-atomic-clang.h:82:16: note: expanded from macro
> 'atomic_add_explicit'
> ../lib/netdev.c:2044:5: error: address argument to atomic operation must
> be
> a pointer to _Atomic type ('const uint64_t *' (aka 'const unsigned long *')
> invalid)
> ../lib/ovs-atomic-clang.h:53:15: note: expanded from macro
> 'atomic_read_explicit'
>
> and many more instances.
>
> GCC says:
>
> ../lib/netdev.c:2044:5: error: incorrect type in argument 1 (different
> modifiers)
> ../lib/netdev.c:2044:5:expected void *
> ../lib/netdev.c:2044:5:got unsigned long const *
> ../lib/netdev.c:2044:5: error: incorrect type in argument 1 (different
> modifiers)
> ../lib/netdev.c:2044:5:expected void *
> ../lib/netdev.c:2044:5:got unsigned long const *
>
> I do tend to think it's correct, otherwise. I wonder how this has been missed
> for so long.
>
> Thanks,
>
> Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH net 1/2] openvswitch: support asymmetric conntrack
Downloading from patchwork is working for me. Its strange other
patches in my mailbox does not has this issue.
Thanks.
On Mon, Nov 25, 2019 at 7:39 AM Aaron Conole wrote:
>
> Aaron Conole writes:
>
> > Pravin Shelar writes:
> >
> >> On Fri, Nov 8, 2019 at 1:07 PM Aaron Conole wrote:
> >>>
> >>> The openvswitch module shares a common conntrack and NAT infrastructure
> >>> exposed via netfilter. It's possible that a packet needs both SNAT and
> >>> DNAT manipulation, due to e.g. tuple collision. Netfilter can support
> >>> this because it runs through the NAT table twice - once on ingress and
> >>> again after egress. The openvswitch module doesn't have such capability.
> >>>
> >>> Like netfilter hook infrastructure, we should run through NAT twice to
> >>> keep the symmetry.
> >>>
> >>> Fixes: 05752523e565 ("openvswitch: Interface with NAT.")
> >>> Signed-off-by: Aaron Conole
> >>
> >> The patch looks ok. But I am not able apply it. can you fix the encoding.
> >
> > Hrrm. I didn't make any special changes (just used git send-email). I
> > will look at spinning a second patch.
>
> Pravin,
>
> I tried the following:
>
> 10:36:59 aconole@dhcp-25 {(312434617cb1...)} ~/git/linux$ curl
> http://patchwork.ozlabs.org/patch/1192219/mbox/ > test.patch
> % Total% Received % Xferd Average Speed TimeTime Time
> Current
>Dload Upload Total SpentLeft
> Speed
> 100 4827 100 48270 0 8824 0 --:--:-- --:--:-- --:--:--
> 8808
> 10:37:21 aconole@dhcp-25 {(312434617cb1...)} ~/git/linux$ git am test.patch
> Applying: openvswitch: support asymmetric conntrack
> 10:37:24 aconole@dhcp-25 {(f759cc2b7323...)} ~/git/linux$
>
>
> Can you check your mailer settings? The patchwork mbox worked fine, and
> I was able to apply from my own mbox as well.
>
> -Aaron
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] I look forward to hearing from you.
Dear sir/madam my name Kofi victor presently at refugee camp in Accra my father is a German nationality who work as a foreign consultant and marry to a Liberian which is my late mom who die alone with my father in an accident. He left behind usd$ 12,million dollars at UBA bank Accra which I am seeking a foreign beneficiary to received on my behalf for me to relocated immediately.. Please response to give all details of the bank information.. Thanks. Kofi victor ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [patch v1] faq: Correct fragment reassembly release.
Correct fragment reassembly release for the userspace datapath. Signed-off-by: Darrell Ball --- Documentation/faq/releases.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/faq/releases.rst b/Documentation/faq/releases.rst index 4152345..3b2da08 100644 --- a/Documentation/faq/releases.rst +++ b/Documentation/faq/releases.rst @@ -116,7 +116,7 @@ Q: Are all features available with all datapaths? FeatureLinux upstream Linux OVS tree Userspace Hyper-V == == == = === Connection tracking 4.32.5 2.6 YES -Conntrack Fragment Reass. 4.32.6 2.10 YES +Conntrack Fragment Reass. 4.32.6 2.12 YES Conntrack Timeout Policies 5.22.12 NO NO Conntrack Zone Limit4.18 2.10 NO YES Conntrack NAT 4.62.6 2.8 YES -- 1.9.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] ipf question
Thanks Li,Rongqing
On Mon, Nov 18, 2019 at 9:35 PM Li,Rongqing wrote:
> Thanks, Darrell
>
>
>
> I can try to test it
>
thanks !; can you try this 2 patch series ?
dball@ubuntu:~/openvswitch/ovs$ cat
outgoing2/0001-dp-packet-Cache-batch-action-list-in-batch.patch
From 80436fb57a54ecfd532e99086dbb0e5142415070 Mon Sep 17 00:00:00 2001
From: Darrell Ball
Date: Sun, 24 Nov 2019 17:29:07 -0800
Subject: [patch v1 1/2] dp-packet: Cache batch action list in batch.
To: d...@openvswitch.org
Cache the batch action list in the batch itself. This will be
used in a subsequent patch.
Signed-off-by: Darrell Ball
---
lib/dp-packet.h | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/lib/dp-packet.h b/lib/dp-packet.h
index 14f0897..77df801 100644
--- a/lib/dp-packet.h
+++ b/lib/dp-packet.h
@@ -775,9 +775,11 @@ enum { NETDEV_MAX_BURST = 32 }; /* Maximum number
packets in a batch. */
struct dp_packet_batch {
size_t count;
+size_t actions_len;
+const struct nlattr *actions;
+struct dp_packet *packets[NETDEV_MAX_BURST];
bool trunc; /* true if the batch needs truncate. */
bool do_not_steal; /* Indicate that the packets should not be stolen.
*/
-struct dp_packet *packets[NETDEV_MAX_BURST];
};
static inline void
@@ -786,6 +788,8 @@ dp_packet_batch_init(struct dp_packet_batch *batch)
batch->count = 0;
batch->trunc = false;
batch->do_not_steal = false;
+batch->actions = NULL;
+batch->actions_len = 0;
}
static inline void
@@ -930,6 +934,27 @@ dp_packet_batch_reset_cutlen(struct dp_packet_batch
*batch)
}
}
+static inline void
+dp_packet_batch_set_action_ctx(struct dp_packet_batch *batch,
+ const struct nlattr *actions,
+ size_t actions_len)
+{
+batch->actions = actions;
+batch->actions_len = actions_len;
+}
+
+static inline const struct nlattr *
+dp_packet_batch_get_actions(struct dp_packet_batch *batch)
+{
+return batch->actions;
+}
+
+static inline size_t
+dp_packet_batch_get_action_len(struct dp_packet_batch *batch)
+{
+return batch->actions_len;
+}
+
#ifdef __cplusplus
}
#endif
--
1.9.1
dball@ubuntu:~/openvswitch/ovs$ cat
outgoing2/0002-ipf-Resume-fragments-in-same-action-list.patch
From 4aefd4e791f9d7b6ef916e41136cb59e6020bb22 Mon Sep 17 00:00:00 2001
From: Darrell Ball
Date: Sun, 24 Nov 2019 17:33:58 -0800
Subject: [patch v1 2/2] ipf: Resume fragments in same action list.
To: d...@openvswitch.org
Once fragments are reassembled and go through conntrack, the fragments
need to resume processing in the same action list. There is a
semantic requirement that the list have, at most, one conntrack action,
so this specifies the resume point in the list as well. A memcmp is
used to compare pre and post processing lists as padding is zeroed out,
therefore having predictable values.
Signed-off-by: Darrell Ball
---
lib/dpif-netdev.c | 1 +
lib/ipf.c | 49 -
2 files changed, 37 insertions(+), 13 deletions(-)
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 5142bad..3ddca5b 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -7363,6 +7363,7 @@ dp_netdev_execute_actions(struct dp_netdev_pmd_thread
*pmd,
{
struct dp_netdev_execute_aux aux = { pmd, flow };
+dp_packet_batch_set_action_ctx(packets, actions, actions_len);
odp_execute_actions(, packets, should_steal, actions,
actions_len, dp_execute_cb);
}
diff --git a/lib/ipf.c b/lib/ipf.c
index 45c4891..ad82620 100644
--- a/lib/ipf.c
+++ b/lib/ipf.c
@@ -91,6 +91,8 @@ union ipf_addr {
/* Represents a single fragment; part of a list of fragments. */
struct ipf_frag {
struct dp_packet *pkt;
+struct nlattr *actions;
+size_t actions_len;
uint16_t start_data_byte;
uint16_t end_data_byte;
bool dnsteal; /* 'do not steal': if true, ipf should not free packet.
*/
@@ -261,7 +263,12 @@ ipf_list_clean(struct hmap *frag_lists,
{
ovs_list_remove(_list->list_node);
hmap_remove(frag_lists, _list->node);
-free(ipf_list->frag_list);
+struct ipf_frag *frag_list = ipf_list->frag_list;
+ovs_assert(frag_list);
+for (int i = 0; i <= ipf_list->last_inuse_idx; i++) {
+free(frag_list[i].actions);
+}
+free(frag_list);
free(ipf_list);
}
@@ -793,7 +800,7 @@ static bool
ipf_process_frag(struct ipf *ipf, struct ipf_list *ipf_list,
struct dp_packet *pkt, uint16_t start_data_byte,
uint16_t end_data_byte, bool ff, bool lf, bool v6,
- bool dnsteal)
+ struct dp_packet_batch *pb)
OVS_REQUIRES(ipf->ipf_lock)
{
bool duped_frag = ipf_is_frag_duped(ipf_list->frag_list,
@@ -811,7 +818,11 @@ ipf_process_frag(struct ipf *ipf, struct ipf_list
*ipf_list,
frag->pkt = pkt;
frag->start_data_byte = start_data_byte;
[ovs-dev] PROPUESTA DE NEGOCIO IMPORTANTE
Primero, debo pedir su confianza en esta transacciуn; Esto es totalmente confidencial y secreto. Aunque sй que una transacciуn de esta magnitud harб que cualquiera se sienta preocupado, Pero le aseguro que todo estarб bien al final del dнa. Por favor abra el documento que te enviй. Si estб interesado en trabajar conmigo en esta transacciуn, contбcteme en Tel: +34632805006 Correo electrуnico: abogados.paticiago...@gmail.com Si esta propuesta comercial ofende su йtica moral, acepta mis sinceras disculpas, pero si quieres para alcanzar este objetivo conmigo, contбcteme con su interйs para que podamos comenzar el proceso de reclamo inmediatamente. Se espera que la informaciуn contenida en el archivo adjunto sea confidencial y no se divulgue a un tercero. El contenido del archivo adjunto nos beneficia a los dos y espero un total acuerdo de confidencialidad a la informaciуn en consideraciуn de los convenios mutuos en este documento, con la intenciуn de informaciуn confidencial. Estoy esperando su respuesta inmediata. Cuidadosamente, Patricia Gуmez, abogada. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Purchase Order PO 286495
Hello, Please see the attached PO request and confirm pricing and delivery. We appreciate your help and look forward to hearing from you. Thanks, Jessica Hatfield Procurement Specialist / HollyFrontier Navajo Refining LLC 501 E Main Street Artesia, NM 88210 575-746-5459 (Office) This e-mail may contain information that is privileged and confidential. If you received this message in error, please advise the sender immediately and delete this email. Unless expressly stated, this message is not a digital or electronic signature or a commitment to a binding agreement. CONFIDENTIALITY NOTICE: This e-mail, and any attachments, may contain information that is privileged and confidential.If you received this message in error, please advise the sender immediately by reply e-mail and do not retain any paper or electronic copies of this message or any attachments.Unless expressly stated, nothing contained in this message should be construed as a digital or electronic signature or a commitment to a binding agreement. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Indicadores de compras
Me da mucho gusto saludarte. Es, para mí, un placer poder invitarte a nuestro Curso en Línea "Indicadores de compras para una administración óptima", que se estará llevando a cabo el día Martes 17 de Diciembre con un horario de 10:00 a 17:00 hrs. (hora del centro de México) Diseñar estrategias que permitan la optimización de los principales indicadores del departamento de compras. Objetivos Específicos: - El participante será capaz de alinear los objetivos del departamento de compras con los de toda la organización. - El participante será capaz de medir la eficacia de las estrategias aplicadas por el departamento de compras. - El participante será capaz de cuantificar el ahorro monetario derivado delseguimiento de las estrategias. - El participante será capaz de evaluar el desempeño de los proveedores. Teléfonos: (045) 55 15 54 66 30 - (045) 55 85567293- (045) 5530167085. Solicita información respondiendo a este correo con la palabra Indicadores, junto con los siguientes datos: Nombre: Correo electrónico: Número telefónico: Qué tengas un excelente día Si desea dejar de recibir nuestra promoción favor de responder con la palabra baja o enviar un correo a bajas@ innovalearn.net ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] datapath: make generic netlink group const
Upstream commit:
commit 48e48a70c08a8a68f8697f8b30cb83775bda8001
Author: stephen hemminger
Date: Wed Jul 16 11:25:52 2014 -0700
openvswitch: make generic netlink group const
Generic netlink tables can be const.
Signed-off-by: Stephen Hemminger
Signed-off-by: David S. Miller
The equivalent tables in meter.c and conntrack.c are constified so
it should be safe to do the same for these and will improve
security as well.
Original patch slightly modified for out of tree module.
Passes check-kmod.
Passes Travis.
https://travis-ci.org/gvrose8192/ovs-experimental/builds/616880002
Cc: Stephen Hemminger
Signed-off-by: Greg Rose
---
datapath/datapath.c | 21 +++--
datapath/datapath.h | 2 +-
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/datapath/datapath.c b/datapath/datapath.c
index 8a9e54f..853bfb5 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -71,16 +71,16 @@ static struct genl_family dp_datapath_genl_family;
static const struct nla_policy flow_policy[];
-static struct genl_multicast_group ovs_dp_flow_multicast_group = {
- .name = OVS_FLOW_MCGROUP
+static const struct genl_multicast_group ovs_dp_flow_multicast_group = {
+ .name = OVS_FLOW_MCGROUP,
};
-static struct genl_multicast_group ovs_dp_datapath_multicast_group = {
- .name = OVS_DATAPATH_MCGROUP
+static const struct genl_multicast_group ovs_dp_datapath_multicast_group = {
+ .name = OVS_DATAPATH_MCGROUP,
};
-struct genl_multicast_group ovs_dp_vport_multicast_group = {
- .name = OVS_VPORT_MCGROUP
+const struct genl_multicast_group ovs_dp_vport_multicast_group = {
+ .name = OVS_VPORT_MCGROUP,
};
/* Check if need to build a reply message.
@@ -93,7 +93,8 @@ static bool ovs_must_notify(struct genl_family *family,
struct genl_info *info,
genl_has_listeners(family, genl_info_net(info), group);
}
-static void ovs_notify(struct genl_family *family, struct genl_multicast_group
*grp,
+static void ovs_notify(struct genl_family *family,
+ const struct genl_multicast_group *grp,
struct sk_buff *skb, struct genl_info *info)
{
genl_notify(family, skb, info, GROUP_ID(grp), GFP_KERNEL);
@@ -1442,7 +1443,7 @@ static const struct nla_policy
flow_policy[OVS_FLOW_ATTR_MAX + 1] = {
[OVS_FLOW_ATTR_UFID_FLAGS] = { .type = NLA_U32 },
};
-static struct genl_ops dp_flow_genl_ops[] = {
+static const struct genl_ops dp_flow_genl_ops[] = {
{ .cmd = OVS_FLOW_CMD_NEW,
#ifdef HAVE_GENL_VALIDATE_FLAGS
.validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP,
@@ -1846,7 +1847,7 @@ static const struct nla_policy
datapath_policy[OVS_DP_ATTR_MAX + 1] = {
[OVS_DP_ATTR_USER_FEATURES] = { .type = NLA_U32 },
};
-static struct genl_ops dp_datapath_genl_ops[] = {
+static const struct genl_ops dp_datapath_genl_ops[] = {
{ .cmd = OVS_DP_CMD_NEW,
#ifdef HAVE_GENL_VALIDATE_FLAGS
.validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP,
@@ -2303,7 +2304,7 @@ static const struct nla_policy
vport_policy[OVS_VPORT_ATTR_MAX + 1] = {
[OVS_VPORT_ATTR_NETNSID] = { .type = NLA_S32 },
};
-static struct genl_ops dp_vport_genl_ops[] = {
+static const struct genl_ops dp_vport_genl_ops[] = {
{ .cmd = OVS_VPORT_CMD_NEW,
#ifdef HAVE_GENL_VALIDATE_FLAGS
.validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP,
diff --git a/datapath/datapath.h b/datapath/datapath.h
index ee76662..3bffa1d 100644
--- a/datapath/datapath.h
+++ b/datapath/datapath.h
@@ -237,7 +237,7 @@ static inline struct datapath *get_dp(struct net *net, int
dp_ifindex)
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;
+extern const struct genl_multicast_group ovs_dp_vport_multicast_group;
void ovs_dp_process_packet(struct sk_buff *skb, struct sw_flow_key *key);
void ovs_dp_detach_port(struct vport *);
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Some global prize-winning reads & the most-clicked books in Australia! BookConcierge offers over 30 million Bestseller Books, Academic & Specialist Texts! Find, Preview, Discover the cheape
BookConcierge is the worlds biggest online bookstore & lowest-price determinator in 23 countries. Price. Speed. Variety: only the Best & Cheapest & F [http://australia.bookconcierge.co] - Prize Winning Reads on BookConcierge [http://australia.bookconcierge.co]- [http://australia.bookconcierge.co/9780525590453/The-Testaments] [http://australia.bookconcierge.co/9781787331402/Frankissstein] [http://australia.bookconcierge.co/9781787331914/Quichotte] [http://australia.bookconcierge.co/9781910296967/Ducks-Newburyport] [http://australia.bookconcierge.co/9780571340286/Lanny] [http://australia.bookconcierge.co/9780241268025/The-Man-Who-Saw-Everything] [http://australia.bookconcierge.co/9780571298709/The-Wall] [http://australia.bookconcierge.co/9780241364901/Girl-Woman-Other] [http://australia.bookconcierge.co/9780702239090/Bigger-or-Better-Australia-s-Population-Debate] [http://australia.bookconcierge.co/9780670079278/A-Larger-Australia-The-Abc-2015-Boyer-Lectures] [http://australia.bookconcierge.co/9780670075737/Men-and-Women-of-Australia] [http://australia.bookconcierge.co/9781921372407/Human-Rights-Overboard-Seeking-Asylum-in-Australia] - The most clicked books on BookConcierge Australia [http://australia.bookconcierge.co/]- [http://australia.bookconcierge.co/9781847941497/Never-Split-the-Difference] [http://australia.bookconcierge.co/9781925483598/The-Subtle-Art-of-Not-Giving-a-F-Ck] [http://australia.bookconcierge.co/9781524850623/Why-My-Cat-Is-More-Impressive-Than-Your-Baby] [http://australia.bookconcierge.co/9780241257401/Daring-Greatly] [http://australia.bookconcierge.co/9781846041242/Man-s-Search-for-Meaning] [http://australia.bookconcierge.co/9781401956752/Overdeliver] [http://australia.bookconcierge.co/9781847941831/Atomic-Habits] [http://australia.bookconcierge.co/9780571334650/Normal-People] -We support local writers past, present, future on BookConcierge [http://australia.bookconcierge.co]- [http://australia.bookconcierge.co] [http://australia.bookconcierge.co] WITH OVER 30 MILLION BOOKS, BOOKCONCIERGE [http://australia.bookconcierge.co] IS HERE TO HELP YOU EMBRACE THE ZEITGEIST OF YOUR TIMES, IN YOUR COUNTRY AND IN THE WORLD. AS THE LARGEST ONLINE BOOKSTORE IN THE WORLD, WE LET YOU CHOOSE THE CHEAPEST, FASTEST-DELIVERED BOOK-SOURCING OPTIONS IN THE WORLD. [http://australia.bookconcierge.co] [http://australia.bookconcierge.co] [https://www.facebook.com/bookconciergeHK/] [http://australia.bookconcierge.co] [https://www.instagram.com/bookconciergebooks/] Click on any pics above and start book-browsing! [http://australia.bookconcierge.co] WE SERVE YOU THE BOOK-LOVER, BOOK-READER AND BOOK-NEEDER! You can unsubscribe [https://bimaculatus.eomail2.com/unsubscribe?l=e654ee0b-7016-11e9-9307-06b4694bee2a=eb045051-7016-11e9-9307-06b4694bee2a=f5a1cf6b-0227-11ea-be00-06b4694bee2a=campaign=1574719202=1574719213=81694e2f532e7b52629f474cd9dbe6e8e9432a375e0daee407753577986bdd04] at any time although we will be very sad to see you go! The BookConcierge Group www.bookconcierge.co [http://www.bookconcierge.co] ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1] netdev: use acquire-release semantics for change_seq in netdev
On Mon, Nov 18, 2019 at 10:46:59AM +0800, Yanqin Wei wrote:
> "rxq_enabled" of netdev is writen in the vhost thread and read by pmd
> thread once it observes 'change_seq' is updated. This patch is to keep
> order on aarch64 or other weak memory model CPU to ensure 'rxq_enabled' is
> observed before 'change_seq'.
>
> Reviewed-by: Gavin Hu
> Signed-off-by: Yanqin Wei
Thanks for the patch.
This does not compile. Clang says:
In file included from ../lib/dpif-netdev.c:54:
../lib/netdev-provider.h:97:5: error: address argument to atomic operation
must be a pointer to _Atomic type ('uint64_t *' (aka 'unsigned long *') invalid)
../lib/ovs-atomic-clang.h:82:16: note: expanded from macro
'atomic_add_explicit'
In file included from ../lib/dpif-netdev.c:54:
../lib/netdev-provider.h:99:9: error: address argument to atomic operation
must be a pointer to _Atomic type ('uint64_t *' (aka 'unsigned long *') invalid)
../lib/ovs-atomic-clang.h:82:16: note: expanded from macro
'atomic_add_explicit'
../lib/netdev.c:2044:5: error: address argument to atomic operation must be
a pointer to _Atomic type ('const uint64_t *' (aka 'const unsigned long *')
invalid)
../lib/ovs-atomic-clang.h:53:15: note: expanded from macro
'atomic_read_explicit'
and many more instances.
GCC says:
../lib/netdev.c:2044:5: error: incorrect type in argument 1 (different
modifiers)
../lib/netdev.c:2044:5:expected void *
../lib/netdev.c:2044:5:got unsigned long const *
../lib/netdev.c:2044:5: error: incorrect type in argument 1 (different
modifiers)
../lib/netdev.c:2044:5:expected void *
../lib/netdev.c:2044:5:got unsigned long const *
I do tend to think it's correct, otherwise. I wonder how this has been
missed for so long.
Thanks,
Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofproto: Fix crash on PACKET_OUT due to recursive locking after upcall.
On Fri, Nov 01, 2019 at 10:24:39PM +0100, Ilya Maximets wrote: > Handling of OpenFlow PACKET_OUT implies pushing the packet through > the datapath and packet processing inside the datapath could trigger > an upcall. In case of system datapath, 'dpif_execute()' sends packet > to the kernel module and returns. If any, upcall will be triggered > inside the kernel and handled by a separate thread in userspace. > But in case of userspace datapath full processing of the packet happens > inside the 'dpif_execute()' in the same thread that handled PACKET_OUT. > This causes an issue if upcall will lead to modification of flow rules. Thank you very much for the fix. It is simpler and cleaner than I expected. It looks correct to me and it passes all of the tests for me locally. Acked-by: Ben Pfaff ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] CDMX: Planes de carrera y sucesión
06 de Diciembre | Horario de 10:00 A 13:30 Y 15:00 A 18:30 HRS | (hora del centro de México) | PRESENCIAL - CDMX: Planes de carrera y sucesión - La empresa moderna se enfrenta entre otras problemáticas a la rotación de personal. Los nuevos colaboradores buscan crecimiento y desarrollo de vida en una organización. El no disponer de un estudio de planes de carrera del personal puede suponer un factor de desmotivación de los trabajadores/as, que ven limitada su capacidad de ascenso y mejora en las condiciones de trabajo. ¿Qué aprenderás?: - El participante identificará los lineamientos estratégicos para establecer planes de vida y carrera dentro de la organización. - El participante conocerá los principales objetivos y finalidades de los planes de desarrollo dentro de una empresa. - El participante definirá técnicas de valuación diagnóstica para identificar competencias clave. - El participante revisará estrategias de entrenamiento para elevar el potencial de sus colaboradores. Solicita información respondiendo a este correo con la palabra Plan, junto con los siguientes datos: Nombre: Correo electrónico: Número telefónico: Números de Atención: (045) 55 15 54 66 30 - (045) 55 85567293 - (045) 5530167085 En caso de que haya recibido este correo sin haberlo solicitado o si desea dejar de recibir nuestra promoción favor de responder con la palabra baja o enviar un correo a bajas@ innovalearn.net ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] vswitch.xml: Replace non-ASCII characters.
On Mon, Nov 25, 2019 at 03:08:44PM +0100, Ilya Maximets wrote:
> On 25.11.2019 13:51, Flavio Leitner wrote:
> > On Mon, 25 Nov 2019 11:11:44 +0100
> > Ilya Maximets wrote:
> >
> >> This fixes OSX build on Travis:
> >>
> >> ovs-vswitchd.conf.db.5:4061: warning: invalid input character code 128
> >> ovs-vswitchd.conf.db.5:4061: warning: invalid input character code 156
> >>
> >> Fixes: aa453e319961 ("ofproto-dpif: Expose datapath ND Extensions
> >> capability to ovsdb") Signed-off-by: Ilya Maximets
> >> ---
> >> vswitchd/vswitch.xml | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >
> > Do you think it would be useful if checkpatch.py catch that?
>
> Yes, I thought about this. This is task that hard for humans,
> but very simple for a script. One thing is that I don't know to
> which files we should apply this 'ASCII-only' policy. For now
> it could be just for vswitch.xml as it's known to produce build
> issues.
I think it would be reasonable to apply it to all *.xml files with the
possible exception of ofproto/ipfix.xml.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] PROPUESTA DE NEGOCIO IMPORTANTE
Primero, debo pedir su confianza en esta transacciуn; Esto es totalmente confidencial y secreto. Aunque sй que una transacciуn de esta magnitud harб que cualquiera se sienta preocupado, Pero le aseguro que todo estarб bien al final del dнa. Por favor abra el documento que te enviй. Si estб interesado en trabajar conmigo en esta transacciуn, contбcteme en Tel: +34632805006 Correo electrуnico: abogados.paticiago...@gmail.com Si esta propuesta comercial ofende su йtica moral, acepta mis sinceras disculpas, pero si quieres para alcanzar este objetivo conmigo, contбcteme con su interйs para que podamos comenzar el proceso de reclamo inmediatamente. Se espera que la informaciуn contenida en el archivo adjunto sea confidencial y no se divulgue a un tercero. El contenido del archivo adjunto nos beneficia a los dos y espero un total acuerdo de confidencialidad a la informaciуn en consideraciуn de los convenios mutuos en este documento, con la intenciуn de informaciуn confidencial. Estoy esperando su respuesta inmediata. Cuidadosamente, Patricia Gуmez, abogada. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH net 1/2] openvswitch: support asymmetric conntrack
Aaron Conole writes:
> Pravin Shelar writes:
>
>> On Fri, Nov 8, 2019 at 1:07 PM Aaron Conole wrote:
>>>
>>> The openvswitch module shares a common conntrack and NAT infrastructure
>>> exposed via netfilter. It's possible that a packet needs both SNAT and
>>> DNAT manipulation, due to e.g. tuple collision. Netfilter can support
>>> this because it runs through the NAT table twice - once on ingress and
>>> again after egress. The openvswitch module doesn't have such capability.
>>>
>>> Like netfilter hook infrastructure, we should run through NAT twice to
>>> keep the symmetry.
>>>
>>> Fixes: 05752523e565 ("openvswitch: Interface with NAT.")
>>> Signed-off-by: Aaron Conole
>>
>> The patch looks ok. But I am not able apply it. can you fix the encoding.
>
> Hrrm. I didn't make any special changes (just used git send-email). I
> will look at spinning a second patch.
Pravin,
I tried the following:
10:36:59 aconole@dhcp-25 {(312434617cb1...)} ~/git/linux$ curl
http://patchwork.ozlabs.org/patch/1192219/mbox/ > test.patch
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft Speed
100 4827 100 48270 0 8824 0 --:--:-- --:--:-- --:--:-- 8808
10:37:21 aconole@dhcp-25 {(312434617cb1...)} ~/git/linux$ git am test.patch
Applying: openvswitch: support asymmetric conntrack
10:37:24 aconole@dhcp-25 {(f759cc2b7323...)} ~/git/linux$
Can you check your mailer settings? The patchwork mbox worked fine, and
I was able to apply from my own mbox as well.
-Aaron
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [dpdk-latest PATCH v3] netdev-dpdk: add coverage counter to count vhost IRQs
When the dpdk vhost library executes an eventfd_write() call,
i.e. waking up the guest, a new callback will be called.
This patch adds the callback to count the number of
interrupts sent to the VM to track the number of times
interrupts where generated.
This might be of interest to find out system-calls were
called in the DPDK fast path.
The coverage counter is called "vhost_notification" and
can be read with:
$ ovs-appctl coverage/read-counter vhost_notification
13238319
Signed-off-by: Eelco Chaudron
---
v2 -> v3
- rebased on latest dpdk-latest
- renamed coverage counter name to vhost_notification
- limit commit message line length
v1 -> v2
- Moved to using a coverage counter
lib/netdev-dpdk.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 2423d26..b20f5da 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -74,6 +74,7 @@ VLOG_DEFINE_THIS_MODULE(netdev_dpdk);
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 20);
COVERAGE_DEFINE(vhost_tx_contention);
+COVERAGE_DEFINE(vhost_notification);
#define DPDK_PORT_WATCHDOG_INTERVAL 5
@@ -168,6 +169,8 @@ static int new_device(int vid);
static void destroy_device(int vid);
static int vring_state_changed(int vid, uint16_t queue_id, int enable);
static void destroy_connection(int vid);
+static void vhost_guest_notified(int vid);
+
static const struct vhost_device_ops virtio_net_device_ops =
{
.new_device = new_device,
@@ -176,6 +179,7 @@ static const struct vhost_device_ops virtio_net_device_ops =
.features_changed = NULL,
.new_connection = NULL,
.destroy_connection = destroy_connection,
+.guest_notified = vhost_guest_notified,
};
/* Custom software stats for dpdk ports */
@@ -3844,6 +3848,12 @@ destroy_connection(int vid)
}
}
+static
+void vhost_guest_notified(int vid OVS_UNUSED)
+{
+COVERAGE_INC(vhost_notification);
+}
+
/*
* Retrieve the DPDK virtio device ID (vid) associated with a vhostuser
* or vhostuserclient netdev.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] vswitch.xml: Replace non-ASCII characters.
On Mon, 25 Nov 2019 15:08:44 +0100
Ilya Maximets wrote:
> On 25.11.2019 13:51, Flavio Leitner wrote:
> > On Mon, 25 Nov 2019 11:11:44 +0100
> > Ilya Maximets wrote:
> >
> >> This fixes OSX build on Travis:
> >>
> >> ovs-vswitchd.conf.db.5:4061: warning: invalid input character code
> >> 128 ovs-vswitchd.conf.db.5:4061: warning: invalid input character
> >> code 156
> >>
> >> Fixes: aa453e319961 ("ofproto-dpif: Expose datapath ND Extensions
> >> capability to ovsdb") Signed-off-by: Ilya Maximets
> >> ---
> >> vswitchd/vswitch.xml | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >
> > Do you think it would be useful if checkpatch.py catch that?
>
> Yes, I thought about this. This is task that hard for humans,
> but very simple for a script. One thing is that I don't know to
> which files we should apply this 'ASCII-only' policy. For now
> it could be just for vswitch.xml as it's known to produce build
> issues.
I don't know either, but that sounds like a good start.
> Do you want to make a patch?
Unfortunately not in the next couple weeks. If anyone doesn't get it
until there, I can do it.
fbl
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] vswitch.xml: Replace non-ASCII characters.
On 25.11.2019 13:51, Flavio Leitner wrote:
> On Mon, 25 Nov 2019 11:11:44 +0100
> Ilya Maximets wrote:
>
>> This fixes OSX build on Travis:
>>
>> ovs-vswitchd.conf.db.5:4061: warning: invalid input character code 128
>> ovs-vswitchd.conf.db.5:4061: warning: invalid input character code 156
>>
>> Fixes: aa453e319961 ("ofproto-dpif: Expose datapath ND Extensions
>> capability to ovsdb") Signed-off-by: Ilya Maximets
>> ---
>> vswitchd/vswitch.xml | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> Do you think it would be useful if checkpatch.py catch that?
Yes, I thought about this. This is task that hard for humans,
but very simple for a script. One thing is that I don't know to
which files we should apply this 'ASCII-only' policy. For now
it could be just for vswitch.xml as it's known to produce build
issues.
Do you want to make a patch?
>
> Acked-by: Flavio Leitner
Thanks! Applied to master.
Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v15] Improved Packet Drop Statistics in OVS
On 25.11.2019 14:10, Eelco Chaudron wrote:
> Anju are you going to sent a v16 with the change?
>
> Ilya putting your new email address on CC, to make sure you have no further
> comments…
My comments are mostly the same as was for the previous versions.
They wasn't fixed. 'lib' files still includes 'ofproto' headers,
non-kernel coding style in kernel headers, 'enum xlate_error'
duplicated now for unknown reason..
>
> //Eelco
>
>
> On 11 Nov 2019, at 15:51, Eelco Chaudron wrote:
>
>> On 8 Nov 2019, at 6:02, Anju Thomas wrote:
>>
>>> Currently OVS maintains explicit packet drop/error counters only on port
>>> level. Packets that are dropped as part of normal OpenFlow processing are
>>> counted in flow stats of “drop” flows or as table misses in table stats.
>>> These can only be interpreted by controllers that know the semantics of the
>>> configured OpenFlow pipeline.
>>> Without that knowledge, it is impossible for an OVS user to obtain e.g. the
>>> total number of packets dropped due to OpenFlow rules.
>>>
>>> Furthermore, there are numerous other reasons for which packets can be
>>> dropped by OVS slow path that are not related to the OpenFlow pipeline.
>>> The generated datapath flow entries include a drop action to avoid further
>>> expensive upcalls to the slow path, but subsequent packets dropped by the
>>> datapath are not accounted anywhere.
>>>
>>> Finally, the datapath itself drops packets in certain error situations.
>>> Also, these drops are today not accounted for.This makes it difficult for
>>> OVS users to monitor packet drop in an OVS instance and to alert a
>>> management system in case of a unexpected increase of such drops.
>>> Also OVS trouble-shooters face difficulties in analysing packet drops.
>>>
>>> With this patch we implement following changes to address the issues
>>> mentioned above.
>>>
>>> 1. Identify and account all the silent packet drop scenarios
>>>
>>> 2. Display these drops in ovs-appctl coverage/show
>>>
>>> Co-authored-by: Rohith Basavaraja
>>> Co-authored-by: Keshav Gupta
>>> Signed-off-by: Anju Thomas
>>> Signed-off-by: Rohith Basavaraja
>>> Signed-off-by: Keshav Gupta
>>> Acked-by: Eelco Chaudron >
>> Not sure what is happening, but your patches show up from “Sriram Vatala via
>> dev”
>>
>>
>>> ---
>>
>>
>>> diff --git a/lib/odp-util.c b/lib/odp-util.c
>>> index 3a574bf..2f8544b 100644
>>> --- a/lib/odp-util.c
>>> +++ b/lib/odp-util.c
>>> @@ -45,6 +45,7 @@
>>> #include "openvswitch/match.h"
>>> #include "odp-netlink-macros.h"
>>> #include "csum.h"
>>> +#include "ofproto/ofproto-dpif-xlate.h"
>>>
>>> VLOG_DEFINE_THIS_MODULE(odp_util);
>>>
>>> @@ -141,6 +142,7 @@ odp_action_len(uint16_t type)
>>> case OVS_ACTION_ATTR_PUSH_NSH: return ATTR_LEN_VARIABLE;
>>> case OVS_ACTION_ATTR_POP_NSH: return 0;
>>> case OVS_ACTION_ATTR_CHECK_PKT_LEN: return ATTR_LEN_VARIABLE;
>>> + case OVS_ACTION_ATTR_DROP: return sizeof(uint32_t);
>>>
>>> case OVS_ACTION_ATTR_UNSPEC:
>>> case __OVS_ACTION_ATTR_MAX:
>>> @@ -1238,6 +1240,9 @@ format_odp_action(struct ds *ds, const struct nlattr
>>> *a,
>>> case OVS_ACTION_ATTR_CHECK_PKT_LEN:
>>> format_odp_check_pkt_len_action(ds, a, portno_names);
>>> break;
>>> + case OVS_ACTION_ATTR_DROP:
>>> + ds_put_cstr(ds, "drop");
>>> + break;
>>> case OVS_ACTION_ATTR_UNSPEC:
>>> case __OVS_ACTION_ATTR_MAX:
>>> default:
>>> @@ -2573,8 +2578,10 @@ odp_actions_from_string(const char *s, const struct
>>> simap *port_names,
>>> struct ofpbuf *actions)
>>> {
>>> size_t old_size;
>>> + enum xlate_error drop_action;
>>
>> Remove the above, as it’s not used. Make sure you use the --enable-Werror
>> when doing ./configure as it will catch these errors.
>>
>>
>> Rest looks good to me…
>>
>> ___
>> 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 v15] Improved Packet Drop Statistics in OVS
Anju are you going to sent a v16 with the change?
Ilya putting your new email address on CC, to make sure you have no
further comments…
//Eelco
On 11 Nov 2019, at 15:51, Eelco Chaudron wrote:
On 8 Nov 2019, at 6:02, Anju Thomas wrote:
Currently OVS maintains explicit packet drop/error counters only on
port level. Packets that are dropped as part of normal OpenFlow
processing are counted in flow stats of “drop” flows or as table
misses in table stats. These can only be interpreted by controllers
that know the semantics of the configured OpenFlow pipeline.
Without that knowledge, it is impossible for an OVS user to obtain
e.g. the total number of packets dropped due to OpenFlow rules.
Furthermore, there are numerous other reasons for which packets can
be dropped by OVS slow path that are not related to the OpenFlow
pipeline.
The generated datapath flow entries include a drop action to avoid
further expensive upcalls to the slow path, but subsequent packets
dropped by the datapath are not accounted anywhere.
Finally, the datapath itself drops packets in certain error
situations.
Also, these drops are today not accounted for.This makes it difficult
for OVS users to monitor packet drop in an OVS instance and to alert
a management system in case of a unexpected increase of such drops.
Also OVS trouble-shooters face difficulties in analysing packet
drops.
With this patch we implement following changes to address the issues
mentioned above.
1. Identify and account all the silent packet drop scenarios
2. Display these drops in ovs-appctl coverage/show
Co-authored-by: Rohith Basavaraja
Co-authored-by: Keshav Gupta
Signed-off-by: Anju Thomas
Signed-off-by: Rohith Basavaraja
Signed-off-by: Keshav Gupta
Acked-by: Eelco Chaudron
Not sure what is happening, but your patches show up from “Sriram
Vatala via dev”
---
diff --git a/lib/odp-util.c b/lib/odp-util.c
index 3a574bf..2f8544b 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -45,6 +45,7 @@
#include "openvswitch/match.h"
#include "odp-netlink-macros.h"
#include "csum.h"
+#include "ofproto/ofproto-dpif-xlate.h"
VLOG_DEFINE_THIS_MODULE(odp_util);
@@ -141,6 +142,7 @@ odp_action_len(uint16_t type)
case OVS_ACTION_ATTR_PUSH_NSH: return ATTR_LEN_VARIABLE;
case OVS_ACTION_ATTR_POP_NSH: return 0;
case OVS_ACTION_ATTR_CHECK_PKT_LEN: return ATTR_LEN_VARIABLE;
+case OVS_ACTION_ATTR_DROP: return sizeof(uint32_t);
case OVS_ACTION_ATTR_UNSPEC:
case __OVS_ACTION_ATTR_MAX:
@@ -1238,6 +1240,9 @@ format_odp_action(struct ds *ds, const struct
nlattr *a,
case OVS_ACTION_ATTR_CHECK_PKT_LEN:
format_odp_check_pkt_len_action(ds, a, portno_names);
break;
+case OVS_ACTION_ATTR_DROP:
+ds_put_cstr(ds, "drop");
+break;
case OVS_ACTION_ATTR_UNSPEC:
case __OVS_ACTION_ATTR_MAX:
default:
@@ -2573,8 +2578,10 @@ odp_actions_from_string(const char *s, const
struct simap *port_names,
struct ofpbuf *actions)
{
size_t old_size;
+enum xlate_error drop_action;
Remove the above, as it’s not used. Make sure you use the
--enable-Werror when doing ./configure as it will catch these errors.
Rest looks good to me…
___
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] vswitch.xml: Replace non-ASCII characters.
On Mon, 25 Nov 2019 11:11:44 +0100
Ilya Maximets wrote:
> This fixes OSX build on Travis:
>
> ovs-vswitchd.conf.db.5:4061: warning: invalid input character code 128
> ovs-vswitchd.conf.db.5:4061: warning: invalid input character code 156
>
> Fixes: aa453e319961 ("ofproto-dpif: Expose datapath ND Extensions
> capability to ovsdb") Signed-off-by: Ilya Maximets
> ---
> vswitchd/vswitch.xml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Do you think it would be useful if checkpatch.py catch that?
Acked-by: Flavio Leitner
>
> diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
> index 09e7bdf5f..b311ef278 100644
> --- a/vswitchd/vswitch.xml
> +++ b/vswitchd/vswitch.xml
> @@ -5830,7 +5830,7 @@ ovs-vsctl add-port br0 p0 -- set Interface p0
> type=patch options:peer=p1 \
> True if the datapath supports OVS_KEY_ATTR_ND_EXTENSIONS
> to match on
> -ICMPv6 "ND reserved" and “ND option type“ header fields. If
> false,
> +ICMPv6 "ND reserved" and "ND option type" header fields. If
> false, the datapath reports error if the feature is used.
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] dp-packet: Fix clearing/copying of memory layout flags.
On 25.11.2019 12:23, Ilya Maximets wrote: > On 24.11.2019 21:38, David Marchand wrote: >> On Fri, Nov 22, 2019 at 3:04 PM Ilya Maximets wrote: >> Rather than exclude a set of flags, I would touch/copy only the flags >> that OVS uses/understands. >> >> When OVS uses a DPDK flag, it has an associated API and meaning wrt >> the rte_mbuf and the data. >> - when the flags are reset in OVS, that's because something has been >> done to the data (and the checksums and the rss hash must be >> reevaluated), >> - when a buffer is copied, OVS copies the data and the context that >> matters to OVS, >> >> Anything else should be discarded when copying to a new dp-packet. > > Yes, that was the first version I wanted to implement, i.e. to collect > all the flags that OVS really uses and clear/copy only these flags. > > But then I started to think about 'ring' ports and that we might send > mbufs with incorrect flags set after the packet modification to the > external application. This doesn't sound good. Because if OVS doesn't > use them doesn't mean that other applications doesn't. So, I've end up > with the current logic with clearing everything except the memory layout > flags. > > Does it make sense? What do you think? Before sending a packet through a dpdk ring, OVS will touch the data and update the relevant flags as far as it is concerned. The application can read/touch those mbuf flags as long as it complies with the DPDK APIs, this concerns both the flags that OVS is aware of, and the rest. So when getting this mbuf back, the flags should be valid. After this, OVS can do what it wants on the packet, it will only touch the flags it understands. What am I missing? >>> >>> I agree that OVS itself will work OK by only considering flags it >>> really uses. I'm concerned about the second application that receives >>> mbuf from the OVS via ring port. For example, I see that ixgbe driver >>> almost unconditionally parses vlans and sets PKT_RX_VLAN along with >>> mbuf->vlan_tci. If OVS will not clear this flag while sending to >> >> - Well, as I said, if OVS touches the data (pops a vlan), it must >> update the flags (PKT_RX_VLAN). > > I don't think that DPDK API requires that anyhow. Otherwise, DPDK s/Otherwise/Contrariwise/ > must ensure that RX flags are valid after receiving mbuf from the > DPDK port, but that is not true for ring pmd. > >> This is overkill if the mbuf does not leave OVS, so it could be >> cleared unconditionally before jumping in the ring. > > That is unclear why we should act differently for ring ports if we > could just clear everything always and there is already generic > API for that (dp_packet_reset_offload). > >> - What kind of applications can read those rings? >> Are those dpdk secondary applications? > > I think so. > >> Asking, since we know that the multiprocess stuff is not really that >> robust and/or usable with OVS. > > I had an intention to deprecate ring ports in OVS, firstly because of > the poor level of support and testing, but I'm not sure if anyone uses > them or not. I could prepare the deprecation patch to collect some > opinions. > > BTW, I'm not sure if I ever used ring ports in OVS, maybe once for ivshmem. > And I'm not sure if anyone tests them any regularly (this is highly > unlikely since ring tests are not included even in VSPERF). > > Best regards, Ilya Maximets. > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] dp-packet: Fix clearing/copying of memory layout flags.
On 24.11.2019 21:38, David Marchand wrote: > On Fri, Nov 22, 2019 at 3:04 PM Ilya Maximets wrote: > Rather than exclude a set of flags, I would touch/copy only the flags > that OVS uses/understands. > > When OVS uses a DPDK flag, it has an associated API and meaning wrt > the rte_mbuf and the data. > - when the flags are reset in OVS, that's because something has been > done to the data (and the checksums and the rss hash must be > reevaluated), > - when a buffer is copied, OVS copies the data and the context that > matters to OVS, > > Anything else should be discarded when copying to a new dp-packet. Yes, that was the first version I wanted to implement, i.e. to collect all the flags that OVS really uses and clear/copy only these flags. But then I started to think about 'ring' ports and that we might send mbufs with incorrect flags set after the packet modification to the external application. This doesn't sound good. Because if OVS doesn't use them doesn't mean that other applications doesn't. So, I've end up with the current logic with clearing everything except the memory layout flags. Does it make sense? What do you think? >>> >>> Before sending a packet through a dpdk ring, OVS will touch the data >>> and update the relevant flags as far as it is concerned. >>> >>> The application can read/touch those mbuf flags as long as it complies >>> with the DPDK APIs, this concerns both the flags that OVS is aware of, >>> and the rest. >>> So when getting this mbuf back, the flags should be valid. >>> >>> After this, OVS can do what it wants on the packet, it will only touch >>> the flags it understands. >>> >>> What am I missing? >> >> I agree that OVS itself will work OK by only considering flags it >> really uses. I'm concerned about the second application that receives >> mbuf from the OVS via ring port. For example, I see that ixgbe driver >> almost unconditionally parses vlans and sets PKT_RX_VLAN along with >> mbuf->vlan_tci. If OVS will not clear this flag while sending to > > - Well, as I said, if OVS touches the data (pops a vlan), it must > update the flags (PKT_RX_VLAN). I don't think that DPDK API requires that anyhow. Otherwise, DPDK must ensure that RX flags are valid after receiving mbuf from the DPDK port, but that is not true for ring pmd. > This is overkill if the mbuf does not leave OVS, so it could be > cleared unconditionally before jumping in the ring. That is unclear why we should act differently for ring ports if we could just clear everything always and there is already generic API for that (dp_packet_reset_offload). > - What kind of applications can read those rings? > Are those dpdk secondary applications? I think so. > Asking, since we know that the multiprocess stuff is not really that > robust and/or usable with OVS. I had an intention to deprecate ring ports in OVS, firstly because of the poor level of support and testing, but I'm not sure if anyone uses them or not. I could prepare the deprecation patch to collect some opinions. BTW, I'm not sure if I ever used ring ports in OVS, maybe once for ivshmem. And I'm not sure if anyone tests them any regularly (this is highly unlikely since ring tests are not included even in VSPERF). Best regards, Ilya Maximets. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v3] Require Python 3 and remove support for Python 2.
On Sat, Nov 23, 2019 at 12:47 AM Mark Michelson wrote:
>
> Acked-by: Mark Michelson
Thanks for the review. I applied this patch to master.
Numan
>
> On 11/22/19 12:21 PM, num...@ovn.org wrote:
> > From: Numan Siddique
> >
> > OVS removed the support for Python 2 in the commit [1].
> > And its time we do the same for OVN. Python3 is now mandatory,
> > otherwise configure will fail.
> >
> > This patch takes care of removing Python 2 references.
> >
> > [1] - 1ca0323e7c29("Require Python 3 and remove support for Python 2.")
> >
> > Signed-off-by: Numan Siddique
> > ---
> >
> > v2 -> v3
> > =
> >* Rebased to the latest master
> >
> > v1 -> v2
> > ===
> >* Addressed the review comments from Mark - Removed HAVE_PYTHON3 var
> > and fixed ovn-detrace.in exception seen with python3.
> >
> > Makefile.am | 12 ++--
> > automake.mk | 8 +--
> > build-aux/dpdkstrip.py | 2 +-
> > build-aux/sodepends.py | 2 +-
> > build-aux/soexpand.py | 2 +-
> > configure.ac| 2 -
> > ipsec/ovs-monitor-ipsec.in | 2 +-
> > m4/ovn.m4 | 89 ++---
> > rhel/ovn-fedora.spec.in | 35 +-
> > tests/atlocal.in| 23 ++-
> > tests/checkpatch.at | 12 ++--
> > tests/ovn-controller-vtep.at| 1 -
> > tests/ovn-northd.at | 10 ---
> > tests/ovn.at| 63 -
> > tests/ovsdb-macros.at | 4 --
> > tests/system-kmod-macros.at | 1 -
> > tests/system-userspace-macros.at| 1 -
> > tutorial/ovs-sandbox| 1 +
> > utilities/bugtool/automake.mk | 2 -
> > utilities/checkpatch.py | 3 +-
> > utilities/ovn-detrace.in| 6 +-
> > utilities/ovn-docker-overlay-driver.in | 2 +-
> > utilities/ovn-docker-underlay-driver.in | 2 +-
> > 23 files changed, 36 insertions(+), 249 deletions(-)
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index 1e41e49ea..8eed7a72b 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -71,7 +71,7 @@ endif
> > # foo/__init__.pyc will cause Python to ignore foo.py.
> > run_python = \
> > PYTHONPATH=$(OVS_SRCDIR)/python$(psep)$$PYTHONPATH \
> > - PYTHONDONTWRITEBYTECODE=yes $(PYTHON)
> > + PYTHONDONTWRITEBYTECODE=yes $(PYTHON3)
> >
> > ALL_LOCAL =
> > BUILT_SOURCES =
> > @@ -165,13 +165,13 @@ ro_shell = printf '\043 Generated automatically -- do
> > not modify!-*- buffer-
> >
> > SUFFIXES += .in
> > .in:
> > -
> > $(AM_V_GEN)PYTHONPATH=$(OVS_SRCDIR)/python$(psep)$$PYTHONPATH$(psep)$(srcdir)/python
> > $(PYTHON) $(srcdir)/build-aux/soexpand.py -I$(srcdir) -I$(OVS_SRCDIR) < $<
> > | \
> > - $(PYTHON) $(srcdir)/build-aux/dpdkstrip.py $(DPDKSTRIP_FLAGS) | \
> > +
> > $(AM_V_GEN)PYTHONPATH=$(OVS_SRCDIR)/python$(psep)$$PYTHONPATH$(psep)$(srcdir)/python
> > $(PYTHON3) $(srcdir)/build-aux/soexpand.py -I$(srcdir) -I$(OVS_SRCDIR) <
> > $< | \
> > + $(PYTHON3) $(srcdir)/build-aux/dpdkstrip.py $(DPDKSTRIP_FLAGS) | \
> > sed \
> > -e 's,[@]PKIDIR[@],$(PKIDIR),g' \
> > -e 's,[@]LOGDIR[@],$(LOGDIR),g' \
> > -e 's,[@]DBDIR[@],$(DBDIR),g' \
> > - -e 's,[@]PYTHON[@],$(PYTHON),g' \
> > + -e 's,[@]PYTHON3[@],$(PYTHON3),g' \
> > -e 's,[@]OVN_RUNDIR[@],$(OVN_RUNDIR),g' \
> > -e 's,[@]OVSBUILDDIR[@],$(OVSBUILDDIR),g' \
> > -e 's,[@]VERSION[@],$(VERSION),g' \
> > @@ -197,7 +197,7 @@ SUFFIXES += .xml
> > PKIDIR='$(PKIDIR)' \
> > LOGDIR='$(LOGDIR)' \
> > DBDIR='$(DBDIR)' \
> > - PYTHON='$(PYTHON)' \
> > + PYTHON3='$(PYTHON3)' \
> > RUNDIR='$(RUNDIR)' \
> > OVN_RUNDIR='$(OVN_RUNDIR)' \
> > VERSION='$(VERSION)' \
> > @@ -425,7 +425,7 @@ CLEANFILES += flake8-check
> >
> > include $(srcdir)/manpages.mk
> > $(srcdir)/manpages.mk: $(MAN_ROOTS) build-aux/sodepends.py
> > $(OVS_SRCDIR)/python/build/soutil.py
> > -
> > @PYTHONPATH=$(OVS_SRCDIR)/python$(psep)$$PYTHONPATH$(psep)$(srcdir)/python
> > $(PYTHON) $(srcdir)/build-aux/sodepends.py -I. -I$(srcdir) -I$(OVS_MANDIR)
> > $(MAN_ROOTS) >$(@F).tmp
> > +
> > @PYTHONPATH=$(OVS_SRCDIR)/python$(psep)$$PYTHONPATH$(psep)$(srcdir)/python
> > $(PYTHON3) $(srcdir)/build-aux/sodepends.py -I. -I$(srcdir) -I$(OVS_MANDIR)
> > $(MAN_ROOTS) >$(@F).tmp
> > @if cmp -s $(@F).tmp $@; then \
> > touch $@; \
> > rm -f $(@F).tmp; \
> > diff --git a/automake.mk b/automake.mk
> > index ad801f1e5..591e00751 100644
> > --- a/automake.mk
> > +++ b/automake.mk
> > @@ -6,19 +6,17 @@ CLEANFILES += ovn-architecture.7
> > #
> > # If "python" or "dot" is not available, then we do not add graphical
> >
[ovs-dev] [PATCH] vswitch.xml: Replace non-ASCII characters.
This fixes OSX build on Travis:
ovs-vswitchd.conf.db.5:4061: warning: invalid input character code 128
ovs-vswitchd.conf.db.5:4061: warning: invalid input character code 156
Fixes: aa453e319961 ("ofproto-dpif: Expose datapath ND Extensions capability to
ovsdb")
Signed-off-by: Ilya Maximets
---
vswitchd/vswitch.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
index 09e7bdf5f..b311ef278 100644
--- a/vswitchd/vswitch.xml
+++ b/vswitchd/vswitch.xml
@@ -5830,7 +5830,7 @@ ovs-vsctl add-port br0 p0 -- set Interface p0 type=patch
options:peer=p1 \
True if the datapath supports OVS_KEY_ATTR_ND_EXTENSIONS to match on
-ICMPv6 "ND reserved" and “ND option type“ header fields. If false,
+ICMPv6 "ND reserved" and "ND option type" header fields. If false,
the datapath reports error if the feature is used.
--
2.17.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] iperf tcp issue on veth using afxdp
On 22 Nov 2019, at 19:50, Ilya Maximets wrote: On 22.11.2019 18:51, William Tu wrote: Hi Ilya and Eelco, Yiyang reports very poor TCP performance on his setup and I can also reproduce it on my machine. Somehow I think this might be a kernel issue, but I don't know where to debug this. Need your suggestion about how to debug. So the setup is like the system-traffic, creating 2 namespaces and veth devices and attach to OVS. I do remember to turn off tx offload and ping, UDP, nc (tcp-mode) works fine. TCP using iperf drops to 0Mbps after 4 seconds. The key questions are: * What is your kernel version? * Does it work in generic mode? * Does it work if iperf generates UDP traffic? ex. iperf3 -c 10.1.1.1 -t 3600 -u -b 10G/64 -l 1460 * It seems like a ring breakage or a umem memory leak. So, what are the afxdp related coverage counters? * Does OVS forward packets, i.e. if there something received/sent? Best regards, Ilya Maximets. This looks very much like the issues we had earlier with tap interfaces, this issue was related to OVS not managing the umem ring correctly (and hence running out of buffers). Guess the coverage counters suggested above should show give you a good starting point for debugging. //Eelco ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [RFC v1] netdev-dpdk: Add flow_api support for netdev vports
Currently vport devices with dpif type "system" are rejected as part of
netdev_offload_dpdk_init_flow_api() call. It is correct but we also need
to specify what should be accepted. We should accept vport devices with
dpif type "netdev". This commit add the acceptance of such devices to
netdev_dpdk_flow_api_supported() API. This will allow any vport of type
"netdev" to be considered for offloading by flow_put().
Co-authored-by: Eveline Raine
Signed-off-by: Eveline Raine
Signed-off-by: Ophir Munk
---
lib/netdev-dpdk.c | 6 ++
lib/netdev-offload-dpdk.c | 7 ---
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 2423d26..854259c 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -4428,6 +4428,12 @@ netdev_dpdk_flow_api_supported(struct netdev *netdev)
struct netdev_dpdk *dev;
bool ret = false;
+if (netdev_vport_is_vport_class(netdev->netdev_class) &&
+!strcmp(netdev_get_dpif_type(netdev), "netdev")) {
+ret = true;
+goto out;
+}
+
if (!is_dpdk_class(netdev->netdev_class)) {
goto out;
}
diff --git a/lib/netdev-offload-dpdk.c b/lib/netdev-offload-dpdk.c
index 2804978..1cc5f59 100644
--- a/lib/netdev-offload-dpdk.c
+++ b/lib/netdev-offload-dpdk.c
@@ -759,13 +759,6 @@ netdev_offload_dpdk_flow_del(struct netdev *netdev, const
ovs_u128 *ufid,
static int
netdev_offload_dpdk_init_flow_api(struct netdev *netdev)
{
-if (netdev_vport_is_vport_class(netdev->netdev_class)
-&& !strcmp(netdev_get_dpif_type(netdev), "system")) {
-VLOG_DBG("%s: vport belongs to the system datapath. Skipping.",
- netdev_get_name(netdev));
-return EOPNOTSUPP;
-}
-
return netdev_dpdk_flow_api_supported(netdev) ? 0 : EOPNOTSUPP;
}
--
2.8.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [RFC v1] netdev-dpdk: Add flow_api support for netdev vports
v1:
This patch follows the patch series in
https://patchwork.ozlabs.org/project/openvswitch/list/?series=143209
("netdev-offload: Prerequisites of vport offloading via DPDK"). It enables
vport devices with dpif type "netdev" to be accecpted by dpdk flow API.
Ophir Munk (1):
netdev-dpdk: Add flow_api support for netdev vports
lib/netdev-dpdk.c | 6 ++
lib/netdev-offload-dpdk.c | 7 ---
2 files changed, 6 insertions(+), 7 deletions(-)
--
2.8.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
