[ovs-dev] Questions about megaflow
Hi all,
The ovs ran into a problem in our environment: Flow continuous to upcall(can
not generate corresponding megaflow) , because of flow_put_on_pmd failed.
flow configuration:
ciagent-9-:/Images/fzt/ovs # ovs-ofctl show br0
OFPT_FEATURES_REPLY (xid=0x2): dpid:70c7f2cb5874
n_tables:254, n_buffers:0
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue ext_action set_vlan_vid set_vlan_pcp strip_vlan
mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
1(bond0): addr:70:c7:f2:cb:58:74
config: 0
state: 0
current:10GB-FD
speed: 1 Mbps now, 0 Mbps max
2(test): addr:52:ec:0b:03:38:ab
config: 0
state: 0
current:10MB-FD COPPER
speed: 10 Mbps now, 0 Mbps max
LOCAL(br0): addr:70:c7:f2:cb:58:74
config: 0
state: 0
current:10MB-FD COPPER
speed: 10 Mbps now, 0 Mbps max
ciagent-9-:/Images/fzt/ovs # ovs-ofctl dump-flows br0
cookie=0x0, duration=395.501s, table=0, n_packets=717, n_bytes=70266,
priority=28,ip,in_port=bond0 actions=IN_PORT
cookie=0x0, duration=2015.547s, table=0, n_packets=0, n_bytes=0,
priority=29,ip,nw_dst=198.159.208.0/24 actions=output:test
cookie=0x0, duration=2.763s, table=0, n_packets=0, n_bytes=0,
priority=29,ip,nw_dst=139.159.208.0/24 actions=output:test
Steps to reproduce the problem:
Step1:
Generate an ip stream into bond,
SIP：1.2.1.2 DIP：130.119.101.60 Type:icmp request
A megaflow will be generated:
recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(dst=130.119.101.60/248.0.0.0,frag=no),
packets:751, bytes:73598, used:0.730s, actions:2
Step2:
Delete the flow of “nw_dst=139.159.208.0/24”
ovs-ofctl del-flows br0 "table=0,ip,nw_dst=139.159.208.0/24"
Note: The megaflow of 130.119.101.60 will not be changed.
Step3:
Generate another ip stream into bond,
SIP：1.2.1.2 DIP：168.119.102.61 Type:icmp request
Now, We can find that this stream cannot generate the corresponding megaflow.
It will keep upcalling, and the miss counter in “ovs-appctl dpctl/show” will
keep increasing. If we open the dpif’s debug, can find continuous log of “File
exist”.
Root cause analysis:
The key to lookup cls in fast_path_processing(-->dp_netdev_pmd_lookup_flow) is
different from the one in flow_put_on_pmd(-->dp_netdev_pmd_lookup_flow).
Is there any suggestion to fix this bug? How about the following two
modifications:
1. Use the same key to lookup cls in handler thread
---
lib/dpif-netdev.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index e456cc9..facb9f6 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -3524,10 +3524,12 @@ dpif_netdev_flow_put(struct dpif *dpif, const struct
dpif_flow_put *put)
}
/* Must produce a netdev_flow_key for lookup.
- * Use the same method as employed to create the key when adding
- * the flow to the dplcs to make sure they match. */
-netdev_flow_mask_init(&mask, &match);
-netdev_flow_key_init_masked(&key, &match.flow, &mask);
+ * Must generate key by flow to guarantee that key is the same as the
key in
+ * fast_path_processing().
+ * ps: key.hash will not be used in lookup. */
+miniflow_map_init(&key.mf, &match->flow);
+miniflow_init(&key.mf, &match->flow);
+key.len = netdev_flow_key_size(miniflow_n_values(&key.mf));
if (put->pmd_id == PMD_ID_NULL) {
if (cmap_count(&dp->poll_threads) == 0) {
--
2. Modify the revalidate_ukey__ to delete the megaflow when mask changes
From c7bda1680832a18946b8459f6b937d62b02d0280 Mon Sep 17 00:00:00 2001
From: f00448292 mailto:fuzhan...@huawei.com>>
Date: Mon, 20 Jul 2020 14:44:34 +0800
Subject: [PATCH] NEW
Signed-off-by: f00448292 mailto:fuzhan...@huawei.com>>
---
ofproto/ofproto-dpif-upcall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index 8dfa05b..8a8c233 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -2209,7 +2209,7 @@ revalidate_ukey__(struct udpif *udpif, const struct
udpif_key *ukey,
* tells that the datapath flow is now too generic and must be narrowed
* down. Note that we do not know if the datapath has ignored any of the
* wildcarded bits, so we may be overly conservative here. */
-if (flow_wildcards_has_extra(&dp_mask, ctx.wc)) {
+if (flow_wildcards_equal(&dp_mask, ctx.wc)) {
goto exit;
}
--
Looking forward to your reply.
Thanks.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] OVS-DPDK patch review list update
Hi All, Please see the updated patch review list from this weeks call. Note we've tried to allocate patches under headers to indicate which patches could use attention (e.g. those close to merging or those already under review could be focused on so as to close off the patch). Regards Ian Patch List === Merged === name: travis: Disable check for array of flexible structures in sparse. href: https://patchwork.ozlabs.org/project/openvswitch/list/?series=206492 subm: Ilya Maximets (Red Hat) Why: Required to keep community CI passing. Status: Merged === Merge Candidate (Close to merging) === name: ovsdb: Remove read permission of *.db from others href: https://patchwork.ozlabs.org/project/openvswitch/list/?series=203778 subm: Yi-Hung Wei Why: Possible security concern. Status: Needs review from deployment perspective rather than technical. Acked by Red Hat, will wait for anymore feedback in the next few days before merge. name: travis: Fix kernel download retry. href: https://patchwork.ozlabs.org/project/openvswitch/list/?series=165294 subm: David Marchand (Red hat) why?: Simple CI fix, input was requested to finish the patch, should be short to give. Status: Reviewed. Acked by Red Hat. name: netdev-offload-dpdk: Support vxlan encap offload with load actions href: https://patchwork.ozlabs.org/project/openvswitch/patch/20200730105838.5329-1-el...@mellanox.com/ subm: Eli Britstein (Nvidia) why?: Already reviewed by other nvidia people, can someone take a look pls? Status: Broadcom acked, Intel validated. Ilya to provide feedback. name: netdev-offload-dpdk: Preserve HW statistics for modified flows href: https://patchwork.ozlabs.org/project/openvswitch/patch/20201012142735.5304-1-el...@nvidia.com/ subm: Eli Britstein (Nvidia) why?: Already reviewed by me, can someone else take a look? Status: Broadcom acked, Intel validated. === Review In Progress === name: New LTS and updated release policy. href: https://patchwork.ozlabs.org/project/openvswitch/list/?series=204478 subm: Ilya Maximets (Red Hat) Why: Need agreement community wide on LTS and branch lifecycle process. Status: Needs review/feedback. --- name: Use more sensitive terminology. href: https://patchwork.ozlabs.org/project/openvswitch/list/?series=208454 subm: Ben Pfaff (OVN) Why: Multiple communities making similar changes (e.g. DPDK). Status: Some patches merged, v4 sent for remaining patches, requires review. --- name: ofproto-dpif-xlate: Do not use zero-weight buckets in select groups. href: https://patchwork.ozlabs.org/project/openvswitch/list/?series=112576 subm: Ben Pfaff (OVN) why?: looks correct, still valid, Ilya validated but no response afterward, get closure. Status: Needs review and rebase but close to merging. --- name: ofproto: Fix statistics of datapath operations. href: https://patchwork.ozlabs.org/project/openvswitch/list/?series=180758 subm: zhaozhanxu (???) why?: Error seems simple to fix -- clamp stats down to 0. Status: Needs review/test, Ian acked but reproduction of the issue seems difficult/unlikely (Ilya), awaiting from zhaozhanxu on where/when the issue is seen. --- name: dpdk: Refuse running on cpu >= RTE_MAX_LCORE. href: https://patchwork.ozlabs.org/project/openvswitch/list/?series=185987 subm: David Marchand (Red hat) why?: This patch is a dependency for another patch supporting new thread API in DPDK. David did not respond to last remark, just need a follow-up? Status: Review/testing needed on follow up. Kevin looked at patch, David will send new patch. --- name: netdev-offload-dpdk: Pass L4 proto-id to match in the L3 rte_flow_item href: https://patchwork.ozlabs.org/project/openvswitch/patch/20200710120718.38633-3-sriharsha.basavapa...@broadcom.com/ subm: Sriharsha Basavapatna (Broadcom) why?: Already acked-by Eli Britstein, fixes rte-flow processing in PMDs, could give an additional pair of eyes. Status: Nvidia acked, Intel to review. --- name: tunnel: Set ECN mask bits only when it is matched in the IP header href: https://patchwork.ozlabs.org/project/openvswitch/patch/20200710120718.38633-4-sriharsha.basavapa...@broadcom.com/ subm: Sriharsha Basavapatna (Broadcom) why?: Simple patch, get a look at ofproto/tunnel.c, seems fine from a first approach. Status: Needs review. Mark Gray reviewed, a patch did not apply, outstanding comments required + rebase. --- name: netdev-offload-dpdk: Support vxlan encap offload with load actions href: https://patchwork.ozlabs.org/project/openvswitch/patch/20200730105838.5329-1-el...@mellanox.com/ subm: Eli Britstein (Nvidia) why?: Already reviewed by other nvidia people, can someone take a look pls? Status: Review and testing needed, Intel and Broadcom to help. Broadcom Acked, Intel validated, Ilya to provide feedback. --- name: netdev-offload-dpdk: Preserve HW statistics for modified flows href: https://patchwork.ozlabs.org/project/openvswitch/patch/20200730135237.22157-1-el...@mellanox.com/ subm: Eli Britstein (Nvidia) why?: Already reviewed by m
[ovs-dev] Can You Handle Contract Supply
Good morning, Our company is interested buying Concentrated Oil in large quantities, can you supply this products from your country? Concentrated FDA Oil is a food supplement for Sub-Saharan Horses and Ponies and it was recently found to be sold very cheap in your country than what our company buy in America, SO if you are ready to cooperate with me on this business I will give you the contact of the dealer in your country, so that you can bridge the gap between them and our company and have the product supply direct by your companay and after we share the profit together that is my interest contact me for more details explanations. I awaits your response to the above discussion. Sincerely, John Apiah. ZSJMEOBMBLGYEGFBUHBEZULEEDOYBXTRRQBRSK ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] FBI Headquarters (FBIHQ) Counter-Terrorism Division
UNITED STATES DEPARTMENT OF JUSTICE FEDERAL BUREAU oF INVESTIGATION (FBI). Inspection Division, FBI Headquarters. DEAR ESTEEMED, The FBI is monitoring the coronavirus situation very closely. Our priority is the wellbeing of American citizens and to ensure the safety of people of the world. As the world continues to change with uncertainty, the United States Department and International Government Organizations are responding with Financial Aid globally. With courtesy, the FBI wishes to inform you about your source of funding and about your Eligibility to have been granted great Financial Relief in tune of $15.5 million USD. The ESAAMLG held its 39th Task Force of Senior Officials and 19th Council of Ministers Meetings in British, Great Britain of the United Kingdom on 26-29 March, 2020. More than 300 delegates from the 18 ESAAMLG Member Countries as well as representatives of Cooperating and Supporting Nations and Organizations, such as DRC, the UK, USA, FBI, the Financial Action Task Force (FATF) Secretariat, the World Development Bank, the COMESA, the German Development Agency (GIZ), the IMF, the SADC, the United Nations Office on Drugs and Crime and the United Nations 1267 Sanctions Monitoring Team attended the meetings. The Vice-President of the FATF, Dr Marcus Pleyer also attended the meetings. Hosted by Queen Elizabeth II, of the United Kingdom and 15 other Commonwealth realms., with support of the United States Jurisdiction. ESAAMLG members took this opportunity to also mark the 21 years of existence of the organization since it was launched in Arusha, Tanzania in August 1999. A special report which highlights the major achievements of the organization was issued to commemorate this event. Convened twice a year, the ESAAMLG meetings are designed to facilitate discussions among delegates from Member States and observers on a number of issues in relation to AML/CFT matters. The ESAAMLG Plenaries also provide an opportunity for the delegates to address pertinent issues that require a concerted and harmonized approach in the effective implementation of Anti-Money Laundering and Counter Financing of Terrorism (AML/CFT) measures and Financial Relief Grant Funding's. As an experience sharing platform, the plenary sessions also provide an opportunity to establish partnerships among experts, representatives of Member States, technical partners and observers in AML/CFT. During the meetings, the 2nd Round Mutual Funds Disbursal Report of the United States and Progress/Follow Up Reports of 12 member countries including the Follow up Reports with Re-ratings of UK, Switzerland, Thailand and Germany were considered. Part of the plenary meeting also included considering the 2020 Technical Financial Assistance Response with "$15.5 million" to each of the (50) persons randomly selected worldwide, in order for them and their various regions to be able to navigate the present unprecedented challenges. The Heads of FIUs Meeting and FIU Forum, Working Group on Risk, Compliance and Financial Inclusion, the Budget, Finance and Audit Committee as well as the closed session of the Steering Committee. The typologies studies on “Procurement Corruption in the Public Sector and Associated Money Laundering in the ESAAMLG Region” presented by the RTMG were also approved at the Council’s meeting. NOTICE: During the third meeting, the Federal Bureau of Investigation (FBI) was appointment to handle the secured cash disbursements in the value sum of ($15.5 million USD). As a matter of fact, we are certified to let you know that your “Global Grant Benefit” Shall be delivered to you in cash, as it is already sealed and locked in a; “3D METALLIC CONSIGNMENT BOX” for your favor and we the FBI are bringing the Consignment Box to you, but after you prove your Eligibility by taken care of your ANTI-MONEY LAUNDERING Licensed tax alone. To get started, kindly reconfirm your current details below; Names: Residence: Tel. Numbers: Emails & ID card: As a fiduciary with complex responsibilities, the FBI believes it is fundamental to have a robust and transparent governance framework, so we look forward to welcoming you as one of our own. As the United States and the world deal with the ongoing pandemic, the FBI’s national security and criminal investigative work continues. Use the resources on this page to help keep yourself and your family safe from these and other threats. Protect Yourself, your family, and your wallet from Pandemic Scammers and from emerging crimes against children and financial scams related to the COVID-19 crisis. Reporting Crime,Report COVID-19 Fraud, if you are a victim of a scam or attempted fraud involving COVID-19, you can: you can report suspicious activities and crime by contacting your local FBI office 24 hours a day, seven days a week; You can also submit a tip electronically at tips.fbi.gov. Report it to the FBI’s Internet Crime Complaint Cente
[ovs-dev] [PATCH net v4] net: openvswitch: fix to make sure flow_lookup() is not preempted
The flow_lookup() function uses per CPU variables, which must be called
with BH disabled. However, this is fine in the general NAPI use case
where the local BH is disabled. But, it's also called from the netlink
context. The below patch makes sure that even in the netlink path, the
BH is disabled.
In addition, u64_stats_update_begin() requires a lock to ensure one writer
which is not ensured here. Making it per-CPU and disabling NAPI (softirq)
ensures that there is always only one writer.
Fixes: eac87c413bf9 ("net: openvswitch: reorder masks array based on usage")
Reported-by: Juri Lelli
Signed-off-by: Eelco Chaudron
---
v2: - Add u64_stats_update_begin() sync point protection
- Moved patch to net from net-next branch
v3: - Add comment to flow_lookup() call
- Some update in code comments, and commit message
v4: - Rebase to latest net branch
net/openvswitch/flow_table.c | 58 +-
net/openvswitch/flow_table.h |8 --
2 files changed, 41 insertions(+), 25 deletions(-)
diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index 87c286ad660e..f3486a37361a 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -175,7 +175,7 @@ static struct table_instance *table_instance_alloc(int
new_size)
static void __mask_array_destroy(struct mask_array *ma)
{
- free_percpu(ma->masks_usage_cntr);
+ free_percpu(ma->masks_usage_stats);
kfree(ma);
}
@@ -199,15 +199,15 @@ static void tbl_mask_array_reset_counters(struct
mask_array *ma)
ma->masks_usage_zero_cntr[i] = 0;
for_each_possible_cpu(cpu) {
- u64 *usage_counters = per_cpu_ptr(ma->masks_usage_cntr,
- cpu);
+ struct mask_array_stats *stats;
unsigned int start;
u64 counter;
+ stats = per_cpu_ptr(ma->masks_usage_stats, cpu);
do {
- start = u64_stats_fetch_begin_irq(&ma->syncp);
- counter = usage_counters[i];
- } while (u64_stats_fetch_retry_irq(&ma->syncp, start));
+ start =
u64_stats_fetch_begin_irq(&stats->syncp);
+ counter = stats->usage_cntrs[i];
+ } while (u64_stats_fetch_retry_irq(&stats->syncp,
start));
ma->masks_usage_zero_cntr[i] += counter;
}
@@ -230,9 +230,10 @@ static struct mask_array *tbl_mask_array_alloc(int size)
sizeof(struct sw_flow_mask *) *
size);
- new->masks_usage_cntr = __alloc_percpu(sizeof(u64) * size,
- __alignof__(u64));
- if (!new->masks_usage_cntr) {
+ new->masks_usage_stats = __alloc_percpu(sizeof(struct mask_array_stats)
+
+ sizeof(u64) * size,
+ __alignof__(u64));
+ if (!new->masks_usage_stats) {
kfree(new);
return NULL;
}
@@ -722,6 +723,8 @@ static struct sw_flow *masked_flow_lookup(struct
table_instance *ti,
/* Flow lookup does full lookup on flow table. It starts with
* mask from index passed in *index.
+ * This function MUST be called with BH disabled due to the use
+ * of CPU specific variables.
*/
static struct sw_flow *flow_lookup(struct flow_table *tbl,
struct table_instance *ti,
@@ -731,7 +734,7 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
u32 *n_cache_hit,
u32 *index)
{
- u64 *usage_counters = this_cpu_ptr(ma->masks_usage_cntr);
+ struct mask_array_stats *stats = this_cpu_ptr(ma->masks_usage_stats);
struct sw_flow *flow;
struct sw_flow_mask *mask;
int i;
@@ -741,9 +744,9 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
if (mask) {
flow = masked_flow_lookup(ti, key, mask, n_mask_hit);
if (flow) {
- u64_stats_update_begin(&ma->syncp);
- usage_counters[*index]++;
- u64_stats_update_end(&ma->syncp);
+ u64_stats_update_begin(&stats->syncp);
+ stats->usage_cntrs[*index]++;
+ u64_stats_update_end(&stats->syncp);
(*n_cache_hit)++;
return flow;
}
@@ -762,9 +765,9 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
flow = masked_flow_lookup(ti, key, mask, n_mask_
Re: [ovs-dev] [PATCH net v3] net: openvswitch: fix to make sure flow_lookup() is not preempted
- Original Message -
> From: "Jakub Kicinski"
> To: "Eelco Chaudron"
> Cc: net...@vger.kernel.org, da...@davemloft.net, d...@openvswitch.org,
> pab...@redhat.com, pshe...@ovn.org,
> jle...@redhat.com, bige...@linutronix.de, "i maximets"
> Sent: Saturday, October 17, 2020 1:46:07 AM
> Subject: Re: [PATCH net v3] net: openvswitch: fix to make sure flow_lookup()
> is not preempted
>
> On Thu, 15 Oct 2020 19:09:33 +0200 Eelco Chaudron wrote:
> > The flow_lookup() function uses per CPU variables, which must be called
> > with BH disabled. However, this is fine in the general NAPI use case
> > where the local BH is disabled. But, it's also called from the netlink
> > context. The below patch makes sure that even in the netlink path, the
> > BH is disabled.
> >
> > In addition, u64_stats_update_begin() requires a lock to ensure one writer
> > which is not ensured here. Making it per-CPU and disabling NAPI (softirq)
> > ensures that there is always only one writer.
> >
> > Fixes: eac87c413bf9 ("net: openvswitch: reorder masks array based on
> > usage")
> > Reported-by: Juri Lelli
> > Signed-off-by: Eelco Chaudron
>
> Hi Eelco, looks like this doesn't apply after the 5.10 merges.
>
> Please respin on top of the current net.
Done, just sent out a v4.
//Eelco
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Sala virtual, funciones, controles y herramientas
Buenas tardes Quise aprovechar la oportunidad de hacerte una invitación para tomar nuestro curso: Nombre: Uso de Zoom para reuniones y clases virtuales Horario: de 16:00 am a 19:00 pm. ¿Cuándo?: 31 de Octubre Precio: $ 290,00 + IVA Formato: En línea con interacción en vivo. Lugar: En Vivo desde su computadora Instructor: Sergio Pasos administra y codirige desde hace 3 años una empresa de capacitación profesional en línea que ha dado amplio uso a diversas herramientas de videollamada acumulando más de 1000 horas de coordinación de cursos y reuniones. En la “Nueva Normalidad”, el uso de la videollamada se ha generalizado, obligando a gran cantidad de profesionistas de la educación y otros servicios a hacer uso de esta plataforma, que si bien es sencilla de utilizar, contiene diversas funciones y configuraciones que valen la pena revisar para optimizar el uso de la herramienta Ejes Temáticos: - Apertura de cuenta y configuración de perfil. - Programación e invitación de reuniones. - Manejo y uso de la sala virtual, sus funciones, controles y herramientas del anfitrión. - La reunión desde la perspectiva de los espectadores. - Recomendaciones adicionales. Realizaremos una revisión general de la configuración de la cuenta de Zoom profundizando en las funciones disponibles en el modo “Reunión” para lograr un entendimiento general del correcto uso de la herramienta. Solicita información respondiendo a este correo con la palabra ZOOM, junto con los siguientes datos: Nombre: Correo electrónico: Número telefónico: Email Alterno: Para información inmediata llamar al: (+52) 55 15 54 66 30 - (+52) 55 30 16 70 85 O puede enviarnos un Whatsapp Qué tengas un gran día. Saludos. Innova Learn México - innovalearn. mx - Mérida, Yucatán, México ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] This spring we announce a wonderful competition! Become our customer and win it easily!
Incredible service. Trusted delivery! "Worked well, as I expected!" - By Sean ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
