[ovs-dev] [PATCH v4] Bareudp Tunnel Support

2020-05-25 Thread Martin Varghese 
From: Martin Varghese 

There are various L3 encapsulation standards using UDP being discussed to
leverage the UDP based load balancing capability of different networks.
MPLSoUDP (__ https://tools.ietf.org/html/rfc7510) is one among them.

The Bareudp tunnel provides a generic L3 encapsulation tunnelling support
for tunnelling different L3 protocols like MPLS, IP, NSH etc. inside a UDP
tunnel.

An example to create bareudp device to tunnel MPLS traffic is
given

$ ovs-vsctl add-port br_mpls udp_port -- set interface udp_port \
 type=bareudp options:remote_ip=2.1.1.3
 options:local_ip=2.1.1.2 \
 options:payload_type=0x8847 options:dst_port=6635 \
 options:packet_type="legacy_l3" \
 ofport_request=$bareudp_egress_port

The bareudp device supports special handling for MPLS & IP as
they can have multiple ethertypes. MPLS procotcol can have ethertypes
ETH_P_MPLS_UC (unicast) & ETH_P_MPLS_MC (multicast). IP protocol can have
ethertypes ETH_P_IP (v4) & ETH_P_IPV6 (v6).

The bareudp device to tunnel L3 traffic with multiple ethertypes
(MPLS & IP) can be created by passing the L3 protocol name as string in
the field payload_type. An example to create bareudp device to tunnel
MPLS unicast & multicast traffic is given below.::

$ ovs-vsctl add-port  br_mpls udp_port -- set interface
udp_port \
type=bareudp options:remote_ip=2.1.1.3
options:local_ip=2.1.1.2 \
options:payload_type=mpls options:dst_port=6635 \
options:packet_type="legacy_l3"

Signed-off-by: Martin Varghese 
---
 Documentation/automake.mk |  1 +
 Documentation/faq/bareudp.rst | 62 +++
 Documentation/faq/index.rst   |  1 +
 Documentation/faq/releases.rst|  1 +
 NEWS  |  3 ++
 datapath/linux/compat/include/linux/openvswitch.h | 10 
 lib/dpif-netlink-rtnl.c   | 53 +++
 lib/dpif-netlink.c|  7 ++-
 lib/netdev-vport.c| 24 -
 lib/netdev.h  |  1 +
 ofproto/ofproto-dpif-xlate.c  |  1 +
 tests/system-layer3-tunnels.at| 47 +
 12 files changed, 209 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/faq/bareudp.rst

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index f85c432..ea3475f 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -88,6 +88,7 @@ DOC_SOURCE = \
Documentation/faq/terminology.rst \
Documentation/faq/vlan.rst \
Documentation/faq/vxlan.rst \
+   Documentation/faq/bareudp.rst \
Documentation/internals/index.rst \
Documentation/internals/authors.rst \
Documentation/internals/bugs.rst \
diff --git a/Documentation/faq/bareudp.rst b/Documentation/faq/bareudp.rst
new file mode 100644
index 000..257f20e
--- /dev/null
+++ b/Documentation/faq/bareudp.rst
@@ -0,0 +1,62 @@
+..
+  Licensed under the Apache License, Version 2.0 (the "License"); you may
+  not use this file except in compliance with the License. You may obtain
+  a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+  WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+  License for the specific language governing permissions and limitations
+  under the License.
+
+  Convention for heading levels in Open vSwitch documentation:
+
+  ===  Heading 0 (reserved for the title in a document)
+  ---  Heading 1
+  ~~~  Heading 2
+  +++  Heading 3
+  '''  Heading 4
+
+  Avoid deeper levels because they do not render well.
+
+===
+Bareudp
+===
+
+Q: What is Bareudp?
+
+A: There are various L3 encapsulation standards using UDP being discussed
+   to leverage the UDP based load balancing capability of different
+   networks. MPLSoUDP (__ https://tools.ietf.org/html/rfc7510) is one among
+   them.
+
+   The Bareudp tunnel provides a generic L3 encapsulation tunnelling
+   support for tunnelling different L3 protocols like MPLS, IP, NSH etc.
+   inside a UDP tunnel.
+
+   An example to create bareudp device to tunnel MPLS traffic is given
+   below.::
+
+   $ ovs-vsctl add-port br_mpls udp_port -- set interface udp_port \
+ type=bareudp options:remote_ip=2.1.1.3 options:local_ip=2.1.1.2 \
+ options:payload_type=0x8847 options:dst_port=6635 \
+ options:packet_type="legacy_l3" \
+ ofport_request=$bareudp_egress_port
+
+   The bareudp device supports special

Re: [ovs-dev] [PATCH ovn 0/2] fix ARP processing for FIP traffic

2020-05-25 Thread Han Zhou 
On Mon, May 25, 2020 at 2:55 PM Lorenzo Bianconi <
lorenzo.bianc...@redhat.com> wrote:
>
> Lorenzo Bianconi (2):
>   Revert "Manage ARP process locally in a DVR scenario"
>   northd: manage ARP request locally for FIP traffic
>
>  northd/ovn-northd.8.xml | 49 
>  northd/ovn-northd.c | 71 +++--
>  tests/ovn.at| 42 ++--
>  tests/system-ovn.at | 28 
>  4 files changed, 85 insertions(+), 105 deletions(-)
>
> --
> 2.26.2
>

Thanks Lorenzo for the refactor. It looks clean now and I applied the first
patch. I had some comments on patch 2. It would be helpful if @Dumitru Ceara
 could take a look as well since he review the earlier
version.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn 1/2] Revert "Manage ARP process locally in a DVR scenario"

2020-05-25 Thread Han Zhou 
On Mon, May 25, 2020 at 2:55 PM Lorenzo Bianconi <
lorenzo.bianc...@redhat.com> wrote:
>
> This reverts commit c0bf32d72f8b893bbe3cb64912b0fd259d71555f.
>
> Signed-off-by: Lorenzo Bianconi 
> ---
>  northd/ovn-northd.8.xml | 37 ++--
>  northd/ovn-northd.c | 53 +
>  tests/ovn.at| 14 ---
>  3 files changed, 3 insertions(+), 101 deletions(-)
>
> diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
> index 8f224b07f..9423cbfd1 100644
> --- a/northd/ovn-northd.8.xml
> +++ b/northd/ovn-northd.8.xml
> @@ -2484,46 +2484,13 @@ output;
>  
>
>
> -  
> -
> -  For distributed logical routers where one of the logical
router ports
> -  specifies a redirect-chassis, a priority-400
logical
> -  flow for each dnat_and_snat NAT rules configured.
> -  These flows will allow to properly forward traffic to the
external
> -  connections if available and avoid sending it through the
tunnel.
> -  Assuming the following NAT rule has been configured:
> -
> -
> -
> -external_ip = A;
> -external_mac = B;
> -logical_ip = C;
> -
> -
> -
> -  the following action will be applied:
> -
> -
> -
> -ip.ttl--;
> -reg0 = ip.dst;
> -reg1 = A;
> -eth.src = B;
> -outport = router-port;
> -next;
> -
> -
> -  
> -
>
>  
>IPv4 routing table.  For each route to IPv4 network
N with
>netmask M, on router port P with IP
address
>A and Ethernet
>address E, a logical flow with match ip4.dst
==
> -  N/M, whose priority is
400
> -  + the number of 1-bits in M if the router port is
not a
> -  distributed gateway port, else the priority is the number of
> +  N/M, whose priority is the number
of
>1-bits in M, has the following actions:
>  
>
> @@ -2910,7 +2877,7 @@ icmp4 {
>  
>
>  For each NAT rule in the OVN Northbound database that can
> -be handled in a distributed manner, a priority-200 logical
> +be handled in a distributed manner, a priority-100 logical
>  flow with match ip4.src == B 
>  outport == GW, where GW is
>  the logical router distributed gateway port, with actions
> diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
> index 6ccd84e49..7ae5e45da 100644
> --- a/northd/ovn-northd.c
> +++ b/northd/ovn-northd.c
> @@ -7125,8 +7125,6 @@ build_routing_policy_flow(struct hmap *lflows,
struct ovn_datapath *od,
>  ds_destroy();
>  }
>
> -/* default logical flow prioriry for distributed routes */
> -#define DROUTE_PRIO 400
>  struct parsed_route {
>  struct ovs_list list_node;
>  struct v46_ip prefix;
> @@ -7514,40 +7512,6 @@ build_ecmp_route_flow(struct hmap *lflows, struct
ovn_datapath *od,
>  ds_destroy();
>  }
>
> -static void
> -add_distributed_routes(struct hmap *lflows, struct ovn_datapath *od)
> -{
> -struct ds actions = DS_EMPTY_INITIALIZER;
> -struct ds match = DS_EMPTY_INITIALIZER;
> -
> -for (size_t i = 0; i < od->nbr->n_nat; i++) {
> -const struct nbrec_nat *nat = od->nbr->nat[i];
> -
> -if (strcmp(nat->type, "dnat_and_snat") ||
> -!nat->external_mac) {
> -continue;
> -}
> -
> -bool is_ipv4 = strchr(nat->logical_ip, '.') ? true : false;
> -ds_put_format(, "ip%s.src == %s &&
is_chassis_resident(\"%s\")",
> -  is_ipv4 ? "4" : "6", nat->logical_ip,
> -  nat->logical_port);
> -char *prefix = is_ipv4 ? "" : "xx";
> -ds_put_format(, "outport = %s; eth.src = %s; "
> -  "%sreg0 = ip%s.dst; %sreg1 = %s; next;",
> -  od->l3dgw_port->json_key, nat->external_mac,
> -  prefix, is_ipv4 ? "4" : "6",
> -  prefix, nat->external_ip);
> -ovn_lflow_add(lflows, od, S_ROUTER_IN_IP_ROUTING, DROUTE_PRIO,
> -  ds_cstr(), ds_cstr());
> -ds_clear();
> -ds_clear();
> -}
> -
> -ds_destroy();
> -ds_destroy();
> -}
> -
>  static void
>  add_route(struct hmap *lflows, const struct ovn_port *op,
>const char *lrp_addr_s, const char *network_s, int plen,
> @@ -7569,12 +7533,6 @@ add_route(struct hmap *lflows, const struct
ovn_port *op,
>  }
>  build_route_match(op_inport, network_s, plen, is_src_route, is_ipv4,
>, );
> -/* traffic for internal IPs of logical switch ports must be sent to
> - * the gw controller through the overlay tunnels
> - */
> -if (op->nbrp && !op->nbrp->n_gateway_chassis) {
> -priority += DROUTE_PRIO;
> -}
>
>  struct ds actions = DS_EMPTY_INITIALIZER;
>  ds_put_format(, "ip.ttl--; "REG_ECMP_GROUP_ID" = 0; %sreg0 =
",
> @@ -9231,7 +9189,7 @@ build_lrouter_flows(struct hmap

Re: [ovs-dev] [PATCH ovn 2/2] northd: manage ARP request locally for FIP traffic

2020-05-25 Thread Han Zhou 
On Mon, May 25, 2020 at 2:55 PM Lorenzo Bianconi <
lorenzo.bianc...@redhat.com> wrote:
>
> Introduce 150-priority logical flows for each NAT rule that can
> be handled in a distributed manner to manage ARP request locally
> for FIP traffic. In particular set reg1 and eth.src to NAT external
> ip and NAT external mac respectivelly and do not distribute ARP
> traffic using FIP
>
> Signed-off-by: Lorenzo Bianconi 
> ---
>  northd/ovn-northd.8.xml | 12 
>  northd/ovn-northd.c | 18 +-
>  tests/ovn.at| 28 +---
>  tests/system-ovn.at | 28 
>  4 files changed, 82 insertions(+), 4 deletions(-)
>
> diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
> index 9423cbfd1..5e37d9758 100644
> --- a/northd/ovn-northd.8.xml
> +++ b/northd/ovn-northd.8.xml
> @@ -2875,6 +2875,18 @@ icmp4 {
>  
>
>  
> +  
> +For each NAT rule in the OVN Northbound database that can
> +be handled in a distributed manner, a priorirty-150 logical
> +flow with match ip.src == A 
> +is_chassis_resident(B), where A
> +is NAT logical ip and B is NAT logical port.
> +IP traffic matching the above rule will be managed locally
> +setting reg1 to C and
eth.src
> +to D, where C is NAT external ip and
> +D is NAT external mac.
> +  
> +
>
>  For each NAT rule in the OVN Northbound database that can
>  be handled in a distributed manner, a priority-100 logical
> diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
> index 7ae5e45da..20f0ee2e4 100644
> --- a/northd/ovn-northd.c
> +++ b/northd/ovn-northd.c
> @@ -9181,8 +9181,24 @@ build_lrouter_flows(struct hmap *datapaths, struct
hmap *ports,
>  /* Ingress Gateway Redirect Table: For NAT on a distributed
>   * router, add flows that are specific to a NAT rule.  These
>   * flows indicate the presence of an applicable NAT rule that
> - * can be applied in a distributed manner. */
> + * can be applied in a distributed manner.
> + * Moreover add logical flows to avoid ARP distributing when
the
> + * chassis has a direct connection to the underlay network
through
> + * a localnet port

I think the two flows may be combined, right? Firstly, the match "outport
== DGW" is missing from the new flow. Secondly, the "is_chassis_resident()"
seems to be missing from the original flow. If this understanding is
correct, the both flows just have same match condition, so the actions
should be combined as well.

In addition, I'd suggest to add more clear comment to state the reason why
setting reg1 and eth.src. For example: it is done to make sure when ARP
request is triggered (in next stage), the ARP generated can have the
eth.src = xxx and src IP as yyy, so that it can bypass the flow that
redirect the ARP request to GW node ...

Thanks,
Han

> + */
>  if (distributed) {
> +ds_clear();
> +ds_clear();
> +ds_put_format(,
> +  "ip%s.src == %s &&
is_chassis_resident(\"%s\")",
> +  is_v6 ? "6" : "4", nat->logical_ip,
> +  nat->logical_port);
> +ds_put_format(, "eth.src = %s; %sreg1 = %s;
next;",
> +  nat->external_mac, is_v6 ? "xx" : "",
> +  nat->external_ip);
> +ovn_lflow_add(lflows, od, S_ROUTER_IN_GW_REDIRECT, 150,
> +  ds_cstr(), ds_cstr());
> +
>  ds_clear();
>  ds_put_format(, "ip%s.src == %s && outport == %s",
>is_v6 ? "6" : "4",
> diff --git a/tests/ovn.at b/tests/ovn.at
> index 8fa1a7e1b..15b40ca1e 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -14943,9 +14943,14 @@ ovs-vsctl -- add-port br-int hv2-vif1 -- \
>  set interface hv2-vif1 external-ids:iface-id=sw1-p0 \
>  options:tx_pcap=hv2/vif1-tx.pcap \
>  options:rxq_pcap=hv2/vif1-rx.pcap \
> -ofport-request=1
> +ofport-request=2
> +ovs-vsctl -- add-port br-int hv2-vif2 -- \
> +set interface hv2-vif2 external-ids:iface-id=sw0-p1 \
> +options:tx_pcap=hv2/vif2-tx.pcap \
> +options:rxq_pcap=hv2/vif2-rx.pcap \
> +ofport-request=3
>
> -ovn-nbctl create Logical_Router name=lr0 options:chassis=hv1
> +ovn-nbctl create Logical_Router name=lr0
>  ovn-nbctl ls-add sw0
>  ovn-nbctl ls-add sw1
>
> @@ -14954,13 +14959,16 @@ ovn-nbctl lsp-add sw0 rp-sw0 -- set
Logical_Switch_Port rp-sw0 \
>  type=router options:router-port=sw0 \
>  -- lsp-set-addresses rp-sw0 router
>
> -ovn-nbctl lrp-add lr0 sw1 00:00:02:01:02:03 172.16.1.1/24
2002:0:0:0:0:0:0:1/64
> +ovn-nbctl lrp-add lr0 sw1 00:00:02:01:02:03 172.16.1.1/24
2002:0:0:0:0:0:0:1/64 \
> +-- set Logical_Router_Port sw1

[ovs-dev] Meine Spende

2020-05-25 Thread da . bce 
Ich, Herr Charles W. Jackson Jr. Ich habe Sie für eine Spende von 750.000 € 
ausgewählt. Antworten Sie jacksonj...@gmail.com für Ansprüche
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] 专业定制各行各业数据

2020-05-25 Thread 专业定制各行各业数据 
专业定制各行各业数据
2020年香港企业名录100万物流行业邮箱数据大全126届广交会参展商名录126届广交会采购商名录2020年阿里巴巴国际站数据2018-2019年上半年全国展会名录1000万邮箱数据大全1.5万张国外采购商名片
通過QQ或者E-mail咨詢 Q Q : 
2083925785 E-mail: sales0...@hotmail.com
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v7 5/9] ovn-controller: I-P for ct zone and OVS interface changes in flow output stage.

2020-05-25 Thread Han Zhou 
On Mon, May 25, 2020 at 8:02 AM Numan Siddique  wrote:
>
>
>
> On Sun, May 24, 2020 at 11:32 AM Han Zhou  wrote:
>>
>> On Sat, May 23, 2020 at 11:37 AM Numan Siddique  wrote:
>> >
>> >
>> >
>> > On Sat, May 23, 2020 at 7:30 AM Han Zhou  wrote:
>> >>
>> >> On Fri, May 22, 2020 at 10:29 AM Numan Siddique 
wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Thu, May 21, 2020 at 12:02 PM Han Zhou  wrote:
>> >> >>
>> >> >> On Wed, May 20, 2020 at 12:41 PM  wrote:
>> >> >> >
>> >> >> > From: Numan Siddique 
>> >> >> >
>> >> >> > This patch handles ct zone changes and OVS interface changes
>> >> incrementally
>> >> >> > in the flow output stage.
>> >> >> >
>> >> >> > Any changes to ct zone can be handled by running physical_run()
>> instead
>> >> >> of running
>> >> >> > flow_output_run(). And any changes to OVS interfaces can be
either
>> >> handled
>> >> >> > incrementally (for OVS interfaces representing VIFs) or just
running
>> >> >> > physical_run() (for tunnel and other types of interfaces).
>> >> >> >
>> >> >> > To better handle this, a new engine node 'physical_flow_changes'
is
>> >> added
>> >> >> which
>> >> >> > handles changes to ct zone and OVS interfaces.
>> >> >> >
>> >> >> Hi Numan,
>> >> >>
>> >> > Hi Han,
>> >> >
>> >> > Thanks for the review and comments. Please see below.
>> >> >
>> >> >
>> >> >>
>> >> >> The engine node physical_flow_changes looks weird because it
doesn't
>> >> really
>> >> >> have any data but merely to trigger some compute when VIF changes.
>> >> >> I think it can be handled in a more straightforward way. In fact
there
>> >> was
>> >> >> a miss in my initial I-P patch that there are still global
variables
>> used
>> >> >> in physical.c (my bad):
>> >> >> - localvif_to_ofport
>> >> >> - tunnels
>> >> >> In the principle of I-P engine global variable shouldn't be used
>> because
>> >> >> otherwise there is no way to ensure the dependency graph is
followed.
>> The
>> >> >> current I-P is sitll correct only because interface changes (which
in
>> >> turn
>> >> >> causes the above global var changes) always triggers recompute.
>> >> >>
>> >> >> Now to handle interface changes incrementally, we should simply
move
>> >> these
>> >> >> global vars to engine nodes, and add them as input for flow_output,
>> and
>> >> >> also their input will be OVS_Interface (and probably some other
>> inputs).
>> >> >> With this, the dependency graph would be clear and implementation
of
>> each
>> >> >> input handler will be straightforward. Otherwise, it would be
really
>> hard
>> >> >> to follow the logic and deduce the correctness for all corner
cases,
>> >> >> although it may be correct for normal scenarios that I believe you
>> have
>> >> >> done thorough tests. Do you mind refactoring it?
>> >> >
>> >> >
>> >> > Right now, the flow_output node has an "en_ct_zones" engine as input
>> and
>> >> it doesn't have
>> >> > OVS_interface as input. But this is ok as any runtime data change
will
>> >> trigger recomputing.
>> >> >
>> >> Do you mean OVS_interface should actually be input of "en_ct_zones",
but
>> it
>> >> is ok to not add it? But I don't understand why should it be input of
>> >> en_ct_zones. Maybe I missed something?
>> >
>> >
>> > I mean right now, OVS Interface is not an input to flow_output stage.
>> >
>> >>
>> >> My point above is about the dependency between flow_output and
>> >> OVS_interface. flow_output actually depends on OVS_interface. The two
>> >> global variables allowed flow_output to use OVS_interface data without
>> the
>> >> dependancy in the graph. Now since we incrementally procssing
>> OVS_interface
>> >> changes, we'd better fix the dependency graph to ensure the
correctness.
>> >
>> >
>> > I agree.
>> >
>> >
>> >>
>> >> I
>> >> had encounted very tricky bugs even when some very trivial part of the
>> I-P
>> >> engine rule was not followed, and finally found out defining the
engine
>> >> node properly was the easiest fix.
>> >>
>> >> > If en_ct_zones engine node changes, there is no need to trigger full
>> >> recompute and we
>> >> > call "physical_run()", it should be enough. Although we can
definitely
>> >> further improve it
>> >> > and this can be tackled separately.
>> >> >
>> >> > In my understanding, I think we can also handle ovs interface
changes
>> >> incrementally and if we can't
>> >> > we can just call "physical_run()" instead of full flow recompute.
>> >> >
>> >> > With this patch, it adds an engine node for physical flow changes
and
>> the
>> >> input for that is en_ct_zone
>> >> > and ovs interface. I understand and agree that it's a bit weird.
>> >> >
>> >> > How to handle it when both
>> >> >- en_ct_zone changes
>> >> >-  some ovs interface changes.
>> >> >
>> >> > If both these inputs are direct inputs to the flow_output engine,
then
>> we
>> >> may end up calling "physical_run()"
>> >> > twice. And I wanted to avoid that and hence added a
>> physical_flow_changes
>> >> node as an intermediate.
>> >> > How do you suggest we handle this if we directly

[ovs-dev] Tom crist-spende

2020-05-25 Thread Tom Crist 



Sie haben eine Spende von 4.800.000,00 EURO. Ich habe die Amerika-Lotterie im 
Wert von 40 Millionen US-Dollar in Amerika gewonnen und beschlossen, einen Teil 
davon an fünf glückliche Menschen und Wohltätigkeitsorganisationen zu spenden, 
um an meine verstorbene Frau zu erinnern, die an Krebs gestorben ist. 
Kontaktieren Sie mich für weitere Informationen unter: tomcrist...@gmail.com
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/3] dpif-netlink: Generate ufids for installing TC flowers

2020-05-25 Thread Tonghao Zhang 
On Mon, May 18, 2020 at 10:37 PM Roi Dayan  wrote:
>
>
>
> On 2020-05-18 4:44 AM, xiangxia.m@gmail.com wrote:
> > From: Tonghao Zhang 
> >
> > To support installing the TC flowers to HW, via "ovs-appctl dpctl/add-flow"
> > command, there should be an ufid. This patch will check whether ufid exists,
> > if not, generate an ufid. Should to know that when processing upcall 
> > packets,
> > ufid is generated in parse_odp_packet for kernel datapath.
> >
> > Configuring the max-idle/max-revalidator, may help testing this patch.
> >
> > Cc: Simon Horman 
> > Cc: Paul Blakey 
> > Cc: Roi Dayan 
> > Cc: Ben Pfaff 
> > Cc: William Tu 
> > Cc: Ilya Maximets 
> > Signed-off-by: Tonghao Zhang 
> > ---
> >  lib/dpif-netlink.c | 45 +
> >  1 file changed, 45 insertions(+)
> >
> > diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
> > index dc642100fc58..a19ed7e53566 100644
> > --- a/lib/dpif-netlink.c
> > +++ b/lib/dpif-netlink.c
> > @@ -2231,12 +2231,55 @@ dpif_netlink_operate_chunks(struct dpif_netlink 
> > *dpif, struct dpif_op **ops,
> >  }
> >  }
> >
> > +static void
> > +dpif_netlink_try_update_ufid__(struct dpif_op *op, ovs_u128 *ufid)
> > +{
> > +switch (op->type) {
> > +case DPIF_OP_FLOW_PUT:
> > +if (!op->flow_put.ufid) {
> > +odp_flow_key_hash(op->flow_put.key, op->flow_put.key_len,
> > +  ufid);
> > +op->flow_put.ufid = ufid;
> > +}
> > +break;
> > +case DPIF_OP_FLOW_DEL:
> > +if (!op->flow_del.ufid) {
> > +odp_flow_key_hash(op->flow_del.key, op->flow_del.key_len,
> > +  ufid);
> > +op->flow_del.ufid = ufid;
> > +}
> > +break;
> > +case DPIF_OP_FLOW_GET:
> > +if (!op->flow_get.ufid) {
> > +odp_flow_key_hash(op->flow_get.key, op->flow_get.key_len,
> > +  ufid);
> > +op->flow_get.ufid = ufid;
> > +}
> > +break;
> > +case DPIF_OP_EXECUTE:
> > +default:
> > +break;
> > +}
> > +}
> > +
> > +static void
> > +dpif_netlink_try_update_ufid(struct dpif_op **ops, ovs_u128 *ufid,
> > + size_t n_ops)
> > +{
> > +int i;
> > +
> > +for (i = 0; i < n_ops; i++) {
> > +dpif_netlink_try_update_ufid__(ops[i], [i]);
> > +}
> > +}
> > +
> >  static void
> >  dpif_netlink_operate(struct dpif *dpif_, struct dpif_op **ops, size_t 
> > n_ops,
> >   enum dpif_offload_type offload_type)
> >  {
> >  struct dpif_netlink *dpif = dpif_netlink_cast(dpif_);
> >  struct dpif_op *new_ops[OPERATE_MAX_OPS];
> > +ovs_u128 ufids[OPERATE_MAX_OPS];
> >  int count = 0;
> >  int i = 0;
> >  int err = 0;
> > @@ -2246,6 +2289,8 @@ dpif_netlink_operate(struct dpif *dpif_, struct 
> > dpif_op **ops, size_t n_ops,
> >  return;
> >  }
> >
> > +dpif_netlink_try_update_ufid(ops, ufids, n_ops);
> > +
> >  if (offload_type != DPIF_OFFLOAD_NEVER && 
> > netdev_is_flow_api_enabled()) {
> >  while (n_ops > 0) {
> >  count = 0;
> >
>
> Acked-by: Roi Dayan 
Hi maintainers
It has been 1 week. and reviewed by Roi. I want to see if more
comments, or do you have plan to push them to master. Thanks.
http://patchwork.ozlabs.org/project/openvswitch/patch/20200518014443.1529-1-xiangxia.m@gmail.com/
http://patchwork.ozlabs.org/project/openvswitch/patch/20200518014443.1529-2-xiangxia.m@gmail.com/
http://patchwork.ozlabs.org/project/openvswitch/patch/20200518014443.1529-3-xiangxia.m@gmail.com/



--
Best regards, Tonghao
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Spende

2020-05-25 Thread Tayeb Souami 
Glückwunsch. Ich bin Tayeb Souami Sie haben eine Spende von 2.930.000,00 Euro. 
Am 19. Mai 2019 habe ich 315,3 Millionen Dollar Powerball Lotterie gewonnen. 
Ich möchte einen Teil davon an zehn glückliche Menschen und zehn 
Wohltätigkeitsorganisationen spenden. Ihre E-Mail wurde zufällig als Gewinner 
ausgewählt. Wenden Sie sich an den Spender, um weitere Informationen zu 
erhalten. E-MAIL: tayebx2sou...@gmail.com Mit freundlichen Grüßen Tayeb Souami

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] raft: Avoid sending equal snapshots.

2020-05-25 Thread Han Zhou 
On Mon, May 25, 2020 at 6:11 AM Ilya Maximets  wrote:
>
> On 5/23/20 8:36 PM, Han Zhou wrote:
> >
> >
> > On Sat, May 23, 2020 at 10:34 AM Ilya Maximets mailto:i.maxim...@ovn.org>> wrote:
> >>
> >> Snapshots are huge.  In some cases we could receive several outdated
> >> append replies from the remote server.  This could happen in high
> >> scale cases if the remote server is overloaded and not able to process
> >> all the raft requests in time.  As an action to each outdated append
> >> reply we're sending full database snapshot.  While remote server is
> >> already overloaded those snapshots will stuck in jsonrpc backlog for
> >> a long time making it grow up to few GB.  Since remote server wasn't
> >> able to timely process incoming messages it will likely not able to
> >> process snapshots leading to the same situation with low chances to
> >> recover.  Remote server will likely stuck in 'candidate' state, other
> >> servers will grow their memory consumption due to growing jsonrpc
> >> backlogs:
> >
> > Hi Ilya, this patch LGTM. Just not not clear about this last part of
the commit message. Why would remote server stuck in 'candidate' state if
there are pending messages from leader for it to handle? If the follower
was busy processing older messages, it wouldn't have had a chance to see
election timer timeout without receiving heartbeat from leader, so it
shouldn't try to start voting, right?
>
> I'm not sure what exactly happens, but that is what I see in my setup.
> Overloaded server sends vote requests almost each second with the term
> increased by 1 each time.  I think it doesn't see heartbeats since it
> processes only few messages at a time and a single message processing
> like applying the snapshot could lead to election timer expiration.
>
It processes at most 50 messages at a time for each connection in
raft_conn_run(), which should guarantee append_request (heartbeat) is seen.
However, it is possible that the connection is lost due to inactivity
probe, then append_request could be missed, causing re-election. Did you
see such case after applying the patch that disables inactivity probe for
raft connections?

>
> > Otherwise:
> >
> > Acked-by: Han Zhou mailto:hz...@ovn.org>>
> >
> >>
> >> jsonrpc|INFO|excessive sending backlog, jsonrpc: ssl:192.16.0.3:6644 <
http://192.16.0.3:6644>,
> >>  num of msgs: 3795, backlog: 8838994624.
> >>
> >> This patch is trying to avoid that situation by avoiding sending of
> >> equal snapshot install requests.  This helps maintain reasonable memory
> >> consumption and allows the cluster to recover on a larger scale.
> >>
> >> Signed-off-by: Ilya Maximets >
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2 ovn] ovn: introduce IP_SRC_POLICY stage in ingress router pipeline

2020-05-25 Thread Lorenzo Bianconi 
> Hi Lorenzo,
> 
> Sorry that I replied to v1 right before you send v2. Please check my
> comments there.

Hi Han,

I implemented your suggestions here:
https://patchwork.ozlabs.org/project/openvswitch/cover/cover.1590443438.git.lorenzo.bianc...@redhat.com/
Please note I have not added v3 tag since I changed series name.

Regards,
Lorenzo

> 
> Thanks,
> Han
> 
> On Fri, May 22, 2020 at 1:50 PM Lorenzo Bianconi <
> lorenzo.bianc...@redhat.com> wrote:
> 
> > In order to fix the issues introduced by commit
> > c0bf32d72f8b ("Manage ARP process locally in a DVR scenario "), restore
> > previous configuration of table 9 in ingress router pipeline and
> > introduce a new stage called 'ip_src_policy' used to set the src address
> > info in order to not distribute FIP traffic if DVR is enabled
> >
> > Fixes: c0bf32d72f8b ("Manage ARP process locally in a DVR scenario ")
> > Signed-off-by: Lorenzo Bianconi 
> > ---
> > Changes since v1:
> > - fixed system-ovn.at test
> > - added ovn.at test
> > - fixed documentation
> > ---
> >  northd/ovn-northd.8.xml | 75 +
> >  northd/ovn-northd.c | 38 +
> >  tests/ovn.at| 56 +-
> >  tests/system-ovn.at | 28 +++
> >  4 files changed, 115 insertions(+), 82 deletions(-)
> >
> > diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
> > index 8f224b07f..5e57f5694 100644
> > --- a/northd/ovn-northd.8.xml
> > +++ b/northd/ovn-northd.8.xml
> > @@ -2484,37 +2484,6 @@ output;
> >  
> >
> >
> > -  
> > -
> > -  For distributed logical routers where one of the logical router
> > ports
> > -  specifies a redirect-chassis, a priority-400
> > logical
> > -  flow for each dnat_and_snat NAT rules configured.
> > -  These flows will allow to properly forward traffic to the
> > external
> > -  connections if available and avoid sending it through the
> > tunnel.
> > -  Assuming the following NAT rule has been configured:
> > -
> > -
> > -
> > -external_ip = A;
> > -external_mac = B;
> > -logical_ip = C;
> > -
> > -
> > -
> > -  the following action will be applied:
> > -
> > -
> > -
> > -ip.ttl--;
> > -reg0 = ip.dst;
> > -reg1 = A;
> > -eth.src = B;
> > -outport = router-port;
> > -next;
> > -
> > -
> > -  
> > -
> >
> >  
> >IPv4 routing table.  For each route to IPv4 network
> > N with
> > @@ -2660,7 +2629,41 @@ outport = P;
> >
> >  
> >
> > -Ingress Table 12: ARP/ND Resolution
> > +Ingress Table 12: IP Source Policy
> > +
> > +
> > +  This table contains for distributed logical routers where one of
> > +  the logical router ports specifies a redirect-chassis,
> > +  a priority-100 logical flow for each dnat_and_snat
> > +  NAT rules configured.
> > +  These flows will allow to properly forward traffic to the external
> > +  connections if available and avoid sending it through the tunnel.
> > +  Assuming the following NAT rule has been configured:
> > +
> > +
> > +
> > +external_ip = A;
> > +external_mac = B;
> > +logical_ip = C;
> > +logical_port = D;
> > +
> > +
> > +
> > +  for IP traffic matching ip.src == C 
> > +  is_chassis_resident(D)
> > +
> > +
> > +
> > +  the following action will be applied:
> > +
> > +
> > +
> > +reg1 = A;
> > +eth.src = B;
> > +next;
> > +
> > +
> > +Ingress Table 13: ARP/ND Resolution
> >
> >  
> >Any packet that reaches this table is an IP packet whose next-hop
> > @@ -2819,7 +2822,7 @@ outport = P;
> >
> >  
> >
> > -Ingress Table 13: Check packet length
> > +Ingress Table 14: Check packet length
> >
> >  
> >For distributed logical routers with distributed gateway port
> > configured
> > @@ -2849,7 +2852,7 @@ REGBIT_PKT_LARGER = check_pkt_larger(L);
> > next;
> >and advances to the next table.
> >  
> >
> > -Ingress Table 14: Handle larger packets
> > +Ingress Table 15: Handle larger packets
> >
> >  
> >For distributed logical routers with distributed gateway port
> > configured
> > @@ -2898,7 +2901,7 @@ icmp4 {
> >and advances to the next table.
> >  
> >
> > -Ingress Table 15: Gateway Redirect
> > +Ingress Table 16: Gateway Redirect
> >
> >  
> >For distributed logical routers where one of the logical router
> > @@ -2934,7 +2937,7 @@ icmp4 {
> >
> >  
> >
> > -Ingress Table 16: ARP Request
> > +Ingress Table 17: ARP Request
> >
> >  
> >In the common case where the Ethernet destination has been
> > resolved, this
> > diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
> > index 6ccd84e49..cecaa9ab3 100644
> > --- a/northd/ovn-northd.c
> > +++ b/northd/ovn-northd.c
> > @@ -175,11 +175,12 @@ enum ovn_stage {
> >

[ovs-dev] [PATCH ovn 2/2] northd: manage ARP request locally for FIP traffic

2020-05-25 Thread Lorenzo Bianconi 
Introduce 150-priority logical flows for each NAT rule that can
be handled in a distributed manner to manage ARP request locally
for FIP traffic. In particular set reg1 and eth.src to NAT external
ip and NAT external mac respectivelly and do not distribute ARP
traffic using FIP

Signed-off-by: Lorenzo Bianconi 
---
 northd/ovn-northd.8.xml | 12 
 northd/ovn-northd.c | 18 +-
 tests/ovn.at| 28 +---
 tests/system-ovn.at | 28 
 4 files changed, 82 insertions(+), 4 deletions(-)

diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index 9423cbfd1..5e37d9758 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -2875,6 +2875,18 @@ icmp4 {
 
 
 
+  
+For each NAT rule in the OVN Northbound database that can
+be handled in a distributed manner, a priorirty-150 logical
+flow with match ip.src == A 
+is_chassis_resident(B), where A
+is NAT logical ip and B is NAT logical port.
+IP traffic matching the above rule will be managed locally
+setting reg1 to C and eth.src
+to D, where C is NAT external ip and
+D is NAT external mac.
+  
+
   
 For each NAT rule in the OVN Northbound database that can
 be handled in a distributed manner, a priority-100 logical
diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index 7ae5e45da..20f0ee2e4 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -9181,8 +9181,24 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap 
*ports,
 /* Ingress Gateway Redirect Table: For NAT on a distributed
  * router, add flows that are specific to a NAT rule.  These
  * flows indicate the presence of an applicable NAT rule that
- * can be applied in a distributed manner. */
+ * can be applied in a distributed manner.
+ * Moreover add logical flows to avoid ARP distributing when the
+ * chassis has a direct connection to the underlay network through
+ * a localnet port
+ */
 if (distributed) {
+ds_clear();
+ds_clear();
+ds_put_format(,
+  "ip%s.src == %s && is_chassis_resident(\"%s\")",
+  is_v6 ? "6" : "4", nat->logical_ip,
+  nat->logical_port);
+ds_put_format(, "eth.src = %s; %sreg1 = %s; next;",
+  nat->external_mac, is_v6 ? "xx" : "",
+  nat->external_ip);
+ovn_lflow_add(lflows, od, S_ROUTER_IN_GW_REDIRECT, 150,
+  ds_cstr(), ds_cstr());
+
 ds_clear();
 ds_put_format(, "ip%s.src == %s && outport == %s",
   is_v6 ? "6" : "4",
diff --git a/tests/ovn.at b/tests/ovn.at
index 8fa1a7e1b..15b40ca1e 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -14943,9 +14943,14 @@ ovs-vsctl -- add-port br-int hv2-vif1 -- \
 set interface hv2-vif1 external-ids:iface-id=sw1-p0 \
 options:tx_pcap=hv2/vif1-tx.pcap \
 options:rxq_pcap=hv2/vif1-rx.pcap \
-ofport-request=1
+ofport-request=2
+ovs-vsctl -- add-port br-int hv2-vif2 -- \
+set interface hv2-vif2 external-ids:iface-id=sw0-p1 \
+options:tx_pcap=hv2/vif2-tx.pcap \
+options:rxq_pcap=hv2/vif2-rx.pcap \
+ofport-request=3
 
-ovn-nbctl create Logical_Router name=lr0 options:chassis=hv1
+ovn-nbctl create Logical_Router name=lr0
 ovn-nbctl ls-add sw0
 ovn-nbctl ls-add sw1
 
@@ -14954,13 +14959,16 @@ ovn-nbctl lsp-add sw0 rp-sw0 -- set 
Logical_Switch_Port rp-sw0 \
 type=router options:router-port=sw0 \
 -- lsp-set-addresses rp-sw0 router
 
-ovn-nbctl lrp-add lr0 sw1 00:00:02:01:02:03 172.16.1.1/24 2002:0:0:0:0:0:0:1/64
+ovn-nbctl lrp-add lr0 sw1 00:00:02:01:02:03 172.16.1.1/24 
2002:0:0:0:0:0:0:1/64 \
+-- set Logical_Router_Port sw1 options:redirect-chassis="hv2"
 ovn-nbctl lsp-add sw1 rp-sw1 -- set Logical_Switch_Port rp-sw1 \
 type=router options:router-port=sw1 \
 -- lsp-set-addresses rp-sw1 router
 
 ovn-nbctl lsp-add sw0 sw0-p0 \
 -- lsp-set-addresses sw0-p0 "f0:00:00:01:02:03 192.168.1.2 2001::2"
+ovn-nbctl lsp-add sw0 sw0-p1 \
+-- lsp-set-addresses sw0-p1 "f0:00:00:11:02:03 192.168.1.3 2001::3"
 
 ovn-nbctl lsp-add sw1 sw1-p0 \
 -- lsp-set-addresses sw1-p0 unknown
@@ -15006,6 +15014,20 @@ send_na 2 1 $dst_mac $router_mac1 $dst_ip6 $router_ip6
 
 OVN_CHECK_PACKETS([hv2/vif1-tx.pcap], [expected])
 
+# Create FIP on sw0-p0, add a route on logical router pipeline and
+# ARP request for a unkwon destination is sent using FIP MAC/IP
+ovn-nbctl lr-nat-add lr0 dnat_and_snat 172.16.1.2 192.168.1.3 sw0-p1 
f0:00:00:01:02:04
+ovn-nbctl lr-route-add lr0 172.16.2.0/24 172.16.1.11
+
+dst_ip=$(ip_to_hex 172 16 2 10)
+fip_ip=$(ip_to_hex 172 16 1

[ovs-dev] [PATCH ovn 0/2] fix ARP processing for FIP traffic

2020-05-25 Thread Lorenzo Bianconi 
Lorenzo Bianconi (2):
  Revert "Manage ARP process locally in a DVR scenario"
  northd: manage ARP request locally for FIP traffic

 northd/ovn-northd.8.xml | 49 
 northd/ovn-northd.c | 71 +++--
 tests/ovn.at| 42 ++--
 tests/system-ovn.at | 28 
 4 files changed, 85 insertions(+), 105 deletions(-)

-- 
2.26.2

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH ovn 1/2] Revert "Manage ARP process locally in a DVR scenario"

2020-05-25 Thread Lorenzo Bianconi 
This reverts commit c0bf32d72f8b893bbe3cb64912b0fd259d71555f.

Signed-off-by: Lorenzo Bianconi 
---
 northd/ovn-northd.8.xml | 37 ++--
 northd/ovn-northd.c | 53 +
 tests/ovn.at| 14 ---
 3 files changed, 3 insertions(+), 101 deletions(-)

diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index 8f224b07f..9423cbfd1 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -2484,46 +2484,13 @@ output;
 
   
 
-  
-
-  For distributed logical routers where one of the logical router ports
-  specifies a redirect-chassis, a priority-400 logical
-  flow for each dnat_and_snat NAT rules configured.
-  These flows will allow to properly forward traffic to the external
-  connections if available and avoid sending it through the tunnel.
-  Assuming the following NAT rule has been configured:
-
-
-
-external_ip = A;
-external_mac = B;
-logical_ip = C;
-
-
-
-  the following action will be applied:
-
-
-
-ip.ttl--;
-reg0 = ip.dst;
-reg1 = A;
-eth.src = B;
-outport = router-port;
-next;
-
-
-  
-
   
 
   IPv4 routing table.  For each route to IPv4 network N with
   netmask M, on router port P with IP address
   A and Ethernet
   address E, a logical flow with match ip4.dst ==
-  N/M, whose priority is 400
-  + the number of 1-bits in M if the router port is not a
-  distributed gateway port, else the priority is the number of
+  N/M, whose priority is the number of
   1-bits in M, has the following actions:
 
 
@@ -2910,7 +2877,7 @@ icmp4 {
 
   
 For each NAT rule in the OVN Northbound database that can
-be handled in a distributed manner, a priority-200 logical
+be handled in a distributed manner, a priority-100 logical
 flow with match ip4.src == B 
 outport == GW, where GW is
 the logical router distributed gateway port, with actions
diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index 6ccd84e49..7ae5e45da 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -7125,8 +7125,6 @@ build_routing_policy_flow(struct hmap *lflows, struct 
ovn_datapath *od,
 ds_destroy();
 }
 
-/* default logical flow prioriry for distributed routes */
-#define DROUTE_PRIO 400
 struct parsed_route {
 struct ovs_list list_node;
 struct v46_ip prefix;
@@ -7514,40 +7512,6 @@ build_ecmp_route_flow(struct hmap *lflows, struct 
ovn_datapath *od,
 ds_destroy();
 }
 
-static void
-add_distributed_routes(struct hmap *lflows, struct ovn_datapath *od)
-{
-struct ds actions = DS_EMPTY_INITIALIZER;
-struct ds match = DS_EMPTY_INITIALIZER;
-
-for (size_t i = 0; i < od->nbr->n_nat; i++) {
-const struct nbrec_nat *nat = od->nbr->nat[i];
-
-if (strcmp(nat->type, "dnat_and_snat") ||
-!nat->external_mac) {
-continue;
-}
-
-bool is_ipv4 = strchr(nat->logical_ip, '.') ? true : false;
-ds_put_format(, "ip%s.src == %s && is_chassis_resident(\"%s\")",
-  is_ipv4 ? "4" : "6", nat->logical_ip,
-  nat->logical_port);
-char *prefix = is_ipv4 ? "" : "xx";
-ds_put_format(, "outport = %s; eth.src = %s; "
-  "%sreg0 = ip%s.dst; %sreg1 = %s; next;",
-  od->l3dgw_port->json_key, nat->external_mac,
-  prefix, is_ipv4 ? "4" : "6",
-  prefix, nat->external_ip);
-ovn_lflow_add(lflows, od, S_ROUTER_IN_IP_ROUTING, DROUTE_PRIO,
-  ds_cstr(), ds_cstr());
-ds_clear();
-ds_clear();
-}
-
-ds_destroy();
-ds_destroy();
-}
-
 static void
 add_route(struct hmap *lflows, const struct ovn_port *op,
   const char *lrp_addr_s, const char *network_s, int plen,
@@ -7569,12 +7533,6 @@ add_route(struct hmap *lflows, const struct ovn_port *op,
 }
 build_route_match(op_inport, network_s, plen, is_src_route, is_ipv4,
   , );
-/* traffic for internal IPs of logical switch ports must be sent to
- * the gw controller through the overlay tunnels
- */
-if (op->nbrp && !op->nbrp->n_gateway_chassis) {
-priority += DROUTE_PRIO;
-}
 
 struct ds actions = DS_EMPTY_INITIALIZER;
 ds_put_format(, "ip.ttl--; "REG_ECMP_GROUP_ID" = 0; %sreg0 = ",
@@ -9231,7 +9189,7 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap 
*ports,
   nat->logical_ip,
   od->l3dgw_port->json_key);
 ovn_lflow_add_with_hint(lflows, od, S_ROUTER_IN_GW_REDIRECT,
-200, ds_cstr(), "next;",
+100, ds_cstr(), "next;",

[ovs-dev] Spende

2020-05-25 Thread Tayeb Souami 
Glückwunsch. Ich bin Tayeb Souami Sie haben eine Spende von 2.930.000,00 Euro. 
Am 19. Mai 2019 habe ich 315,3 Millionen Dollar Powerball Lotterie gewonnen. 
Ich möchte einen Teil davon an zehn glückliche Menschen und zehn 
Wohltätigkeitsorganisationen spenden. Ihre E-Mail wurde zufällig als Gewinner 
ausgewählt. Wenden Sie sich an den Spender, um weitere Informationen zu 
erhalten. E-MAIL: tayebx2sou...@gmail.com Mit freundlichen Grüßen Tayeb Souami

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Competencias a desarrollar tras el Covid19

2020-05-25 Thread Responsabilidades y criterios de evaluación 
Jueves 11 de Junio | Horario de 10:00 a 14:00 hrs.  |  (hora del centro de 
México) 

- Competencias a desarrollar durante y después del Covid-19 - Curso en Línea

¿De qué hablaremos?

La pandemia del COVID-19 ha representado una de las peores crisis sociales y 
financieras de la época. Las empresas
se han visto en la necesidad de adaptarse rápidamente a los cambios y 
disposiciones que se les imponen; también han
sufrido un cambio en las prioridades y en lo que genera valor para el negocio.

¿Qué aprenderás?:

- Revisará el modelo de competencias así como sus antecedentes y el panorama 
actual al que se enfrenta el país.
- El participante conocerá las competencias a desarrollar durante el Covid-19, 
definiciones, responsabilidades y criterios de evaluación.
- El participante revisará las competencias a desarrollar después el Covid-19, 
definiciones, responsabilidades y
criterios de evaluación.

Solicita información respondiendo a este correo con la palabra Competencias 
junto con los siguientes datos:

Nombre:
Correo electrónico:
Número telefónico:
Email Alterno:

Pregunte por nuestros cursos grabados y sus costos!

Números de Atención: 

(045) 55 15 54 66 30 - (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

[ovs-dev] [PATCH] tests: add unit test for lb-output-action

2020-05-25 Thread Matteo Croce 
Extend the balance-tcp one so it tests lb-output-action too.
The test checks that that the option is shown in bond/show,
and that the lb_output action is programmed in the datapath.

Signed-off-by: Matteo Croce 
---
 tests/ofproto-dpif.at | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
index 41164d735..dfcfc7161 100644
--- a/tests/ofproto-dpif.at
+++ b/tests/ofproto-dpif.at
@@ -152,6 +152,8 @@ ovs-appctl time/stop
 ovs-appctl time/warp 100
 ovs-appctl lacp/show > lacp.txt
 ovs-appctl bond/show > bond.txt
+# Check that lb_output is not enabled by default
+AT_CHECK([grep -q '^lb-output-action: disabled' bond.txt])
 (
 for i in `seq 0 255` ;
 do
@@ -164,9 +166,32 @@ AT_CHECK([ovs-appctl dpif/dump-flows br0 |grep tcp > 
br0_flows.txt])
 AT_CHECK([ovs-appctl dpif/dump-flows br1 |grep tcp > br1_flows.txt])
 # Make sure there is resonable distribution to all three ports.
 # We don't want to make this check precise, in case hash function changes.
-AT_CHECK([test `grep in_port.4 br1_flows.txt |wc -l` -gt 24])
-AT_CHECK([test `grep in_port.5 br1_flows.txt |wc -l` -gt 24])
-AT_CHECK([test `grep in_port.6 br1_flows.txt |wc -l` -gt 24])
+AT_CHECK([test $(grep -c in_port.4 br1_flows.txt) -gt 24])
+AT_CHECK([test $(grep -c in_port.5 br1_flows.txt) -gt 24])
+AT_CHECK([test $(grep -c in_port.6 br1_flows.txt) -gt 24])
+# Check that bonding is doing dp_hash
+AT_CHECK([grep -q dp_hash br0_flows.txt])
+# Enabling lb_output
+AT_CHECK([ovs-vsctl set Port bond0 other_config:lb-output-action=true])
+OVS_WAIT_UNTIL([ovs-appctl bond/show | grep -q '^lb-output-action: enabled'])
+ovs-appctl time/warp 1 500
+ovs-appctl revalidator/wait
+OVS_WAIT_WHILE([ovs-appctl dpif/dump-flows br1 | grep -q tcp])
+(
+for i in $(seq 256) ;
+do
+
pkt="in_port(7),eth(src=50:54:00:00:00:05,dst=50:54:00:00:01:00),eth_type(0x0800),ipv4(src=10.0.0.2,dst=10.0.0.1,proto=6,tos=0,ttl=64,frag=no),tcp(src=8,dst=$i),tcp_flags(ack)"
+AT_CHECK([ovs-appctl netdev-dummy/receive p7 $pkt])
+done
+)
+ovs-appctl time/warp 300 100
+AT_CHECK([ovs-appctl dpif/dump-flows br0 | grep tcp > br0_flows.txt])
+AT_CHECK([ovs-appctl dpif/dump-flows br1 | grep tcp > br1_flows.txt])
+# Make sure there is resonable distribution to all three ports, again.
+AT_CHECK([test $(grep -c in_port.4 br1_flows.txt) -gt 24])
+AT_CHECK([test $(grep -c in_port.5 br1_flows.txt) -gt 24])
+AT_CHECK([test $(grep -c in_port.6 br1_flows.txt) -gt 24])
+AT_CHECK([grep -q lb_output br0_flows.txt])
 
 OVS_VSWITCHD_STOP()
 AT_CLEANUP
-- 
2.26.2

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] compat: Backport ipv6_stub change

2020-05-25 Thread Ilya Maximets 
On 5/25/20 7:01 PM, Ilya Maximets wrote:
> On 5/24/20 7:59 PM, William Tu wrote:
>> On Thu, May 21, 2020 at 02:54:03PM -0700, Greg Rose wrote:
>>> A patch backported to the Linux stable 4.14 tree and present in the
>>> latest stable 4.14.181 kernel breaks ipv6_stub usage.
>>>
>>> The commit is
>>> 8ab8786f78c3 ("net ipv6_stub: use ip6_dst_lookup_flow instead of 
>>> ip6_dst_lookup").
>>>
>>> Create the compat layer define to check for it and fixup usage in vxlan
>>> and geneve modules.
>>>
>>> Passes Travis here:
>>> https://travis-ci.org/github/gvrose8192/ovs-experimental/builds/689798733
>>>
>>> Signed-off-by: Greg Rose 
>> Thanks for fixing the travis failure.
>> Applied to master.
>> William
> 
> We need to backport this to 2.13 to avoid TravisCI failure on this branch.

And 2.12.

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] parking privé

2020-05-25 Thread Gérard SENROB 
Bonjour,
Si vous êtes propriétaire d’un parking devant votre établissement, sachez que 
vous avez désormais la possibilité d’obtenir une aide de l’état pour y 
installer une BORNE DE RECHARGE pour VOITURES ELECTRIQUES.
L’objectif de l’état étant d’installer plus de 70 000 bornes de recharge d’ici 
3 ans.
Les Hôtels, Restaurants, Entreprises, Commerces, peuvent désormais bénéficier 
de cette aide.
Vous pourrez ainsi bénéficier d’un double avantage :
- Attirer une clientèle à la recherche d'un point de charge (+ 258% de vente de 
véhicules électriques en janvier 2020)
- Créer une source supplémentaire de revenus
C’est vous qui décidez :
•Stationnement et recharges gratuits (vous offrez l'énergie à vos 
collaborateurs, vos clients, vos visiteurs ...)
•Stationnement et recharges payants (une source non négligeable et 
entièrement automatisée avec le paiement par carte ou par téléphone)
•Stationnement et recharges gratuits pour vos clients et payants pour 
les véhicules de passage
Je vous invite à vérifier votre éligibilité à la prime d’installation en 
cliquant ci dessous.
Bien Cordialement
Gérard, S.A.S. SENROB
objectif-prise.fr



 

pour ne plus recevoir de mails de ma part, je vous invite à répondre à ce mail 
en mettant le mot NON dans l'objet

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Попередження щодо облікового запису

2020-05-25 Thread Postmaster via dev 

Шановний користувач ID
Ваші вхідні повідомлення були опубліковані в очікуванні через наше останнє 
оновлення.
Будь ласка, дотримуйтеся наведеної нижче інформаційної посилання, щоб 
підтвердити та оновити свою поштову скриньку та збільшити послугу квот на 
поштову скриньку.
Натисніть тут  щоб оновити вашу поштову скриньку
Просимо вибачення за незручності.
Дякую за співпрацю
Системний адміністратор

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] ovsdb: Fix timeout type for wait operation.

2020-05-25 Thread Ilya Maximets 
According to RFC 7047, 'timeout' is an integer field:

 5.2.6.  Wait
   The "wait" object contains the following members:
  "op": "wait"required
  "timeout": optional
  ...

For some reason initial implementation treated it as a real number.

This causes a build issue with clang that complains that LLONG_MAX
could not be represented as double:

 ovsdb/execution.c:733:32: error: implicit conversion from 'long long'
   to 'double' changes value from
   9223372036854775807 to 9223372036854775808
timeout_msec = MIN(LLONG_MAX, json_real(timeout));
   ^~
 /usr/include/sys/limits.h:69:19: note: expanded from macro 'LLONG_MAX'
 #define LLONG_MAX   __LLONG_MAX /* max for a long long */
^~~
 /usr/include/x86/_limits.h:74:21: note: expanded from macro '__LLONG_MAX'
 #define __LLONG_MAX 0x7fffLL/* max value for a long long */
^~~~
 ./lib/util.h:90:21: note: expanded from macro 'MIN'
 #define MIN(X, Y) ((X) < (Y) ? (X) : (Y))
 ^  ~

Fix that by changing parser to treat 'timeout' as integer.
Fixes clang build on FreeBSD 12.1 in CirrusCI.

Fixes: f85f8ebbfac9 ("Initial implementation of OVSDB.")
Signed-off-by: Ilya Maximets 
---
 ovsdb/execution.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ovsdb/execution.c b/ovsdb/execution.c
index e45f3d679..3a0dad5d0 100644
--- a/ovsdb/execution.c
+++ b/ovsdb/execution.c
@@ -712,7 +712,7 @@ ovsdb_execute_wait(struct ovsdb_execution *x, struct 
ovsdb_parser *parser,
 long long int timeout_msec = 0;
 size_t i;
 
-timeout = ovsdb_parser_member(parser, "timeout", OP_NUMBER | OP_OPTIONAL);
+timeout = ovsdb_parser_member(parser, "timeout", OP_INTEGER | OP_OPTIONAL);
 where = ovsdb_parser_member(parser, "where", OP_ARRAY);
 columns_json = ovsdb_parser_member(parser, "columns",
OP_ARRAY | OP_OPTIONAL);
@@ -730,7 +730,7 @@ ovsdb_execute_wait(struct ovsdb_execution *x, struct 
ovsdb_parser *parser,
 }
 if (!error) {
 if (timeout) {
-timeout_msec = MIN(LLONG_MAX, json_real(timeout));
+timeout_msec = json_integer(timeout);
 if (timeout_msec < 0) {
 error = ovsdb_syntax_error(timeout, NULL,
"timeout must be nonnegative");
-- 
2.25.4

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] compat: Backport ipv6_stub change

2020-05-25 Thread Ilya Maximets 
On 5/24/20 7:59 PM, William Tu wrote:
> On Thu, May 21, 2020 at 02:54:03PM -0700, Greg Rose wrote:
>> A patch backported to the Linux stable 4.14 tree and present in the
>> latest stable 4.14.181 kernel breaks ipv6_stub usage.
>>
>> The commit is
>> 8ab8786f78c3 ("net ipv6_stub: use ip6_dst_lookup_flow instead of 
>> ip6_dst_lookup").
>>
>> Create the compat layer define to check for it and fixup usage in vxlan
>> and geneve modules.
>>
>> Passes Travis here:
>> https://travis-ci.org/github/gvrose8192/ovs-experimental/builds/689798733
>>
>> Signed-off-by: Greg Rose 
> Thanks for fixing the travis failure.
> Applied to master.
> William

We need to backport this to 2.13 to avoid TravisCI failure on this branch.

Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath: Add hash info to upcall.

2020-05-25 Thread Ilya Maximets 
On 5/24/20 8:41 PM, Han Zhou wrote:
> 
> 
> On Thu, May 7, 2020 at 11:21 PM Tonghao Zhang  > wrote:
>>
>> On Mon, May 4, 2020 at 9:02 AM Han Zhou > > wrote:
>> >
>> > This patch backports below upstream patches, and add __skb_set_hash
>> > to compat for older kernels.
>> >
>> > commit b5ab1f1be6180a2e975eede18731804b5164a05d
>> > Author: Jakub Kicinski mailto:k...@kernel.org>>
>> > Date:   Mon Mar 2 21:05:18 2020 -0800
>> >
>> >     openvswitch: add missing attribute validation for hash
>> >
>> >     Add missing attribute validation for OVS_PACKET_ATTR_HASH
>> >     to the netlink policy.
>> >
>> >     Fixes: bd1903b7c459 ("net: openvswitch: add hash info to upcall")
>> >     Signed-off-by: Jakub Kicinski > > >
>> >     Reviewed-by: Greg Rose > > >
>> >     Signed-off-by: David S. Miller > > >
>> >
>> > commit bd1903b7c4596ba6f7677d0dfefd05ba5876707d
>> > Author: Tonghao Zhang > > >
>> > Date:   Wed Nov 13 23:04:49 2019 +0800
>> >
>> >     net: openvswitch: add hash info to upcall
>> >
>> >     When using the kernel datapath, the upcall don't
>> >     include skb hash info relatived. That will introduce
>> >     some problem, because the hash of skb is important
>> >     in kernel stack. For example, VXLAN module uses
>> >     it to select UDP src port. The tx queue selection
>> >     may also use the hash in stack.
>> >
>> >     Hash is computed in different ways. Hash is random
>> >     for a TCP socket, and hash may be computed in hardware,
>> >     or software stack. Recalculation hash is not easy.
>> >
>> >     Hash of TCP socket is computed:
>> >     tcp_v4_connect
>> >         -> sk_set_txhash (is random)
>> >
>> >     __tcp_transmit_skb
>> >         -> skb_set_hash_from_sk
>> >
>> >     There will be one upcall, without information of skb
>> >     hash, to ovs-vswitchd, for the first packet of a TCP
>> >     session. The rest packets will be processed in Open vSwitch
>> >     modules, hash kept. If this tcp session is forward to
>> >     VXLAN module, then the UDP src port of first tcp packet
>> >     is different from rest packets.
>> >
>> >     TCP packets may come from the host or dockers, to Open vSwitch.
>> >     To fix it, we store the hash info to upcall, and restore hash
>> >     when packets sent back.
>> >
>> >     +---+          +-+
>> >     |   Docker/VMs  |          |     ovs-vswitchd        |
>> >     ++--+          +-++--+
>> >          |                       ^                    |
>> >          |                       |                    |
>> >          |                       |  upcall            v restore packet hash
>> > (not recalculate)
>> >          |                     +-++--+
>> >          |  tap netdev         |                         |   vxlan module
>> >          +--->     +-->  Open vSwitch ko     +-->
>> >            or internal type    |                         |
>> >                                +-+
>> >
>> >     Reported-at: 
>> > https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/364062.html
>> >     Signed-off-by: Tonghao Zhang > > >
>> >     Acked-by: Pravin B Shelar mailto:pshe...@ovn.org>>
>> >     Signed-off-by: David S. Miller > > >
>> >
>> > Cc: Tonghao Zhang > > >
>> > Signed-off-by: Han Zhou mailto:hz...@ovn.org>>
>> Reviewed-by: Tonghao Zhang > >
> 
> Thanks review from Tonghao and Greg.
> It has been 3 weeks, so cc some maintainers and pop it up.


Hi.  Thanks for working on this!
There is an issue while building with 3.16 kernel:

ovs/datapath/linux/compat/include/linux/skbuff.h: In function ‘__skb_set_hash’:
ovs/datapath/linux/compat/include/linux/skbuff.h:464:5: error: ‘struct sk_buff’ 
has no member named ‘sw_hash’
  skb->sw_hash = is_sw;
 ^

https://travis-ci.org/github/igsilya/ovs/jobs/690987401

Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] ovs-ctl: Don't overwrite external-id hostname

2020-05-25 Thread Daniel Alvarez 
ovs-ctl started to add the hostname as external-id [0] at some point.

However, this can be problematic as if it's already set by an external
entity it will get overwritten. In RHEL systems, systemd will invoke
ovs-ctl to start OVS and that will overwrite it to the hostname of the
machine.

For OVN this can have a big impact because if, for whatever reason the
hostname changes and the host gets restarted, ovn-controller won't
claim the ports back leaving the workloads unaccessible.

Also, it makes sense to not overwrite it as 1) it's an external_id,
so it will actually let external entities to configure it (unlike now),
and 2) it's optional. In the case that some systems were relying on
ovs-ctl to set the external-id for the first time (e.g onboarding
of a new hypervisor), this patch is not changing such behavior.

For more details, see discussion at [1].

[0] https://mail.openvswitch.org/pipermail/ovs-dev/2016-March/312054.html
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2020-May/370813.html

Signed-off-by: Daniel Alvarez 
---
 utilities/ovs-ctl.in | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
index 8c5cd7032..9be9c9871 100644
--- a/utilities/ovs-ctl.in
+++ b/utilities/ovs-ctl.in
@@ -43,7 +43,8 @@ set_hostname () {
 else
 hn="$(uname -n)"
 fi
-ovs_vsctl set Open_vSwitch . external-ids:hostname="$hn"
+# Set the hostname if it wasn't set before
+ovs_vsctl add Open_vSwitch . external-ids hostname="$hn"
 }

 set_system_ids () {
--

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v7 5/9] ovn-controller: I-P for ct zone and OVS interface changes in flow output stage.

2020-05-25 Thread Numan Siddique 
On Sun, May 24, 2020 at 11:32 AM Han Zhou  wrote:

> On Sat, May 23, 2020 at 11:37 AM Numan Siddique  wrote:
> >
> >
> >
> > On Sat, May 23, 2020 at 7:30 AM Han Zhou  wrote:
> >>
> >> On Fri, May 22, 2020 at 10:29 AM Numan Siddique  wrote:
> >> >
> >> >
> >> >
> >> > On Thu, May 21, 2020 at 12:02 PM Han Zhou  wrote:
> >> >>
> >> >> On Wed, May 20, 2020 at 12:41 PM  wrote:
> >> >> >
> >> >> > From: Numan Siddique 
> >> >> >
> >> >> > This patch handles ct zone changes and OVS interface changes
> >> incrementally
> >> >> > in the flow output stage.
> >> >> >
> >> >> > Any changes to ct zone can be handled by running physical_run()
> instead
> >> >> of running
> >> >> > flow_output_run(). And any changes to OVS interfaces can be either
> >> handled
> >> >> > incrementally (for OVS interfaces representing VIFs) or just
> running
> >> >> > physical_run() (for tunnel and other types of interfaces).
> >> >> >
> >> >> > To better handle this, a new engine node 'physical_flow_changes' is
> >> added
> >> >> which
> >> >> > handles changes to ct zone and OVS interfaces.
> >> >> >
> >> >> Hi Numan,
> >> >>
> >> > Hi Han,
> >> >
> >> > Thanks for the review and comments. Please see below.
> >> >
> >> >
> >> >>
> >> >> The engine node physical_flow_changes looks weird because it doesn't
> >> really
> >> >> have any data but merely to trigger some compute when VIF changes.
> >> >> I think it can be handled in a more straightforward way. In fact
> there
> >> was
> >> >> a miss in my initial I-P patch that there are still global variables
> used
> >> >> in physical.c (my bad):
> >> >> - localvif_to_ofport
> >> >> - tunnels
> >> >> In the principle of I-P engine global variable shouldn't be used
> because
> >> >> otherwise there is no way to ensure the dependency graph is followed.
> The
> >> >> current I-P is sitll correct only because interface changes (which in
> >> turn
> >> >> causes the above global var changes) always triggers recompute.
> >> >>
> >> >> Now to handle interface changes incrementally, we should simply move
> >> these
> >> >> global vars to engine nodes, and add them as input for flow_output,
> and
> >> >> also their input will be OVS_Interface (and probably some other
> inputs).
> >> >> With this, the dependency graph would be clear and implementation of
> each
> >> >> input handler will be straightforward. Otherwise, it would be really
> hard
> >> >> to follow the logic and deduce the correctness for all corner cases,
> >> >> although it may be correct for normal scenarios that I believe you
> have
> >> >> done thorough tests. Do you mind refactoring it?
> >> >
> >> >
> >> > Right now, the flow_output node has an "en_ct_zones" engine as input
> and
> >> it doesn't have
> >> > OVS_interface as input. But this is ok as any runtime data change will
> >> trigger recomputing.
> >> >
> >> Do you mean OVS_interface should actually be input of "en_ct_zones", but
> it
> >> is ok to not add it? But I don't understand why should it be input of
> >> en_ct_zones. Maybe I missed something?
> >
> >
> > I mean right now, OVS Interface is not an input to flow_output stage.
> >
> >>
> >> My point above is about the dependency between flow_output and
> >> OVS_interface. flow_output actually depends on OVS_interface. The two
> >> global variables allowed flow_output to use OVS_interface data without
> the
> >> dependancy in the graph. Now since we incrementally procssing
> OVS_interface
> >> changes, we'd better fix the dependency graph to ensure the correctness.
> >
> >
> > I agree.
> >
> >
> >>
> >> I
> >> had encounted very tricky bugs even when some very trivial part of the
> I-P
> >> engine rule was not followed, and finally found out defining the engine
> >> node properly was the easiest fix.
> >>
> >> > If en_ct_zones engine node changes, there is no need to trigger full
> >> recompute and we
> >> > call "physical_run()", it should be enough. Although we can definitely
> >> further improve it
> >> > and this can be tackled separately.
> >> >
> >> > In my understanding, I think we can also handle ovs interface changes
> >> incrementally and if we can't
> >> > we can just call "physical_run()" instead of full flow recompute.
> >> >
> >> > With this patch, it adds an engine node for physical flow changes and
> the
> >> input for that is en_ct_zone
> >> > and ovs interface. I understand and agree that it's a bit weird.
> >> >
> >> > How to handle it when both
> >> >- en_ct_zone changes
> >> >-  some ovs interface changes.
> >> >
> >> > If both these inputs are direct inputs to the flow_output engine, then
> we
> >> may end up calling "physical_run()"
> >> > twice. And I wanted to avoid that and hence added a
> physical_flow_changes
> >> node as an intermediate.
> >> > How do you suggest we handle this if we directly handle the ovs
> interface
> >> changes in flow_output engine ?
> >> >
> >>
> >> Not sure if I understand completely, but it seems you are suggesting we
> can
> >> afford a recompute for physical

Re: [ovs-dev] [PATCH v5 0/3] Avoid ovsdb-idl IDL inconsistencies.

2020-05-25 Thread Dumitru Ceara 
On 5/7/20 1:20 PM, Dumitru Ceara wrote:
> This series contains:
> - patch1: update to the monitor_cond_change documentation in ovsdb-server to
>   reflect what updates are sent when monitor_cond_since method is used.
> - patch2: fix for a bug that could cause client IDLs to end up in inconsistent
>   states when using OVSDB_MONITOR_V3.
> - patch3: a generic recovery mechanism which triggers an IDL retry with fast
>   resync disabled in case the IDL ended up in an inconsistent state.
> 
> CC: Han Zhou 
> CC: Andy Zhou 
> CC: Ilya Maximets 
> Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection 
> reset.")
> Fixes: db2b5757328c ("lib: add monitor2 support in ovsdb-idl.")
> Signed-off-by: Dumitru Ceara 
> 

Hi Han, Ilya,

Just to make sure this didn't go under your radar, it would be great to
get some feedback about this version.

Thanks,
Dumitru

> Dumitru Ceara (3):
>   ovsdb-server.7: Mention update3 as replies to monitor_cond_change.
>   ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
>   ovsdb-idl: Force IDL retry when missing updates encountered.
> 
> 
>  Documentation/ref/ovsdb-server.7.rst |6 +
>  lib/ovsdb-idl-provider.h |8 +
>  lib/ovsdb-idl.c  |  185 
> +-
>  tests/ovsdb-idl.at   |   56 ++
>  4 files changed, 223 insertions(+), 32 deletions(-)
> 
> 
> ---
> V5:
> - Address Ilya and Han's comments:
>   - Change approach to avoid large number of IDL clients disabling fast
> resync and reconnecting at the same time. We now maintain per table
> acked/requested/new conditions.
>   - Add unit test triggerring the issue fixed in patch 2.
> V4:
> - Address Ilya's comments:
>   - split in series (doc fix + bug fix + recovery mechanism).
>   - use uuid_zero() instead of memset.
>   - move clearing of db->last_id to ovsdb_idl_restart_fsm() and update
> condition such that we cover all cases.
> V3:
> - Change commit title.
> - Update commit message.
> - Fix monitor_cond_since ovsdb-idl implementation.
> V2:
> - Address Mark's comments:
>   - change the error log message to reflect the action taken.
>   - use ovsdb_error() instead of ovsdb_syntax_error().
> 
> ___
> 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] tunnel src port selected when enable tc offload

2020-05-25 Thread Tonghao Zhang 
Hi all,
I find other problem about "hash", when we enable offload with tc,
ovs-vswitchd don't set the tunnel src port, and the tunnel src port
may be decided by nic driver.
the upcall packet will be sent to kernel datapath, which src port
decided by vxlan module.

I guess should we implement the src selected alg as same as kernel ?
-- 
Best regards, Tonghao
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] raft: Avoid sending equal snapshots.

2020-05-25 Thread Ilya Maximets 
On 5/23/20 8:36 PM, Han Zhou wrote:
> 
> 
> On Sat, May 23, 2020 at 10:34 AM Ilya Maximets  > wrote:
>>
>> Snapshots are huge.  In some cases we could receive several outdated
>> append replies from the remote server.  This could happen in high
>> scale cases if the remote server is overloaded and not able to process
>> all the raft requests in time.  As an action to each outdated append
>> reply we're sending full database snapshot.  While remote server is
>> already overloaded those snapshots will stuck in jsonrpc backlog for
>> a long time making it grow up to few GB.  Since remote server wasn't
>> able to timely process incoming messages it will likely not able to
>> process snapshots leading to the same situation with low chances to
>> recover.  Remote server will likely stuck in 'candidate' state, other
>> servers will grow their memory consumption due to growing jsonrpc
>> backlogs:
> 
> Hi Ilya, this patch LGTM. Just not not clear about this last part of the 
> commit message. Why would remote server stuck in 'candidate' state if there 
> are pending messages from leader for it to handle? If the follower was busy 
> processing older messages, it wouldn't have had a chance to see election 
> timer timeout without receiving heartbeat from leader, so it shouldn't try to 
> start voting, right?

I'm not sure what exactly happens, but that is what I see in my setup.
Overloaded server sends vote requests almost each second with the term
increased by 1 each time.  I think it doesn't see heartbeats since it
processes only few messages at a time and a single message processing
like applying the snapshot could lead to election timer expiration.


> Otherwise:
> 
> Acked-by: Han Zhou mailto:hz...@ovn.org>>
> 
>>
>> jsonrpc|INFO|excessive sending backlog, jsonrpc: ssl:192.16.0.3:6644 
>> ,
>>              num of msgs: 3795, backlog: 8838994624.
>>
>> This patch is trying to avoid that situation by avoiding sending of
>> equal snapshot install requests.  This helps maintain reasonable memory
>> consumption and allows the cluster to recover on a larger scale.
>>
>> Signed-off-by: Ilya Maximets mailto:i.maxim...@ovn.org>>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [RFC PATCH] Enable VXLAN TSO for dpdk datapath

2020-05-25 Thread yang_y_yi 
From: Yi Yang 

This patch just show how VXLAN TSO works for developers,
it isn't ready for merge, welcome comments.

Signed-off-by: Yi Yang 
---
 lib/dp-packet.h|  33 +++
 lib/netdev-dpdk.c  | 167 +++--
 lib/netdev-linux.c |  20 +++
 lib/netdev.c   |  16 ++---
 4 files changed, 220 insertions(+), 16 deletions(-)

diff --git a/lib/dp-packet.h b/lib/dp-packet.h
index 0430cca..1ed5eba 100644
--- a/lib/dp-packet.h
+++ b/lib/dp-packet.h
@@ -1032,6 +1032,39 @@ dp_packet_hwol_set_tcp_seg(struct dp_packet *b)
 *dp_packet_ol_flags_ptr(b) |= DP_PACKET_OL_TX_TCP_SEG;
 }
 
+/* Mark packet 'b' for VXLAN TCP segmentation offloading. */
+static inline void
+dp_packet_hwol_set_vxlan_tcp_seg(struct dp_packet *b)
+{
+b->mbuf.ol_flags |= PKT_TX_TUNNEL_VXLAN;
+b->mbuf.l2_len += sizeof(struct udp_header) +
+  sizeof(struct vxlanhdr);
+b->mbuf.outer_l2_len = ETH_HEADER_LEN;
+b->mbuf.outer_l3_len = IP_HEADER_LEN;
+}
+
+/* Set l2_len for the packet 'b' */
+static inline void
+dp_packet_hwol_set_l2_len(struct dp_packet *b, int l2_len)
+{
+b->mbuf.l2_len = l2_len;
+}
+
+/* Set l3_len for the packet 'b' */
+static inline void
+dp_packet_hwol_set_l3_len(struct dp_packet *b, int l3_len)
+{
+b->mbuf.l3_len = l3_len;
+}
+
+/* Set l4_len for the packet 'b' */
+static inline void
+dp_packet_hwol_set_l4_len(struct dp_packet *b, int l4_len)
+{
+b->mbuf.l4_len = l4_len;
+}
+
+
 static inline bool
 dp_packet_ip_checksum_valid(const struct dp_packet *p)
 {
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 44ebf96..bd9696d 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cmap.h"
 #include "coverage.h"
@@ -405,6 +406,7 @@ enum dpdk_hw_ol_features {
 NETDEV_RX_HW_SCATTER = 1 << 2,
 NETDEV_TX_TSO_OFFLOAD = 1 << 3,
 NETDEV_TX_SCTP_CHECKSUM_OFFLOAD = 1 << 4,
+NETDEV_TX_VXLAN_TNL_TSO_OFFLOAD = 1 << 5,
 };
 
 /*
@@ -988,6 +990,12 @@ dpdk_eth_dev_port_config(struct netdev_dpdk *dev, int 
n_rxq, int n_txq)
 
 if (dev->hw_ol_features & NETDEV_TX_TSO_OFFLOAD) {
 conf.txmode.offloads |= DPDK_TX_TSO_OFFLOAD_FLAGS;
+/* Enable VXLAN TSO support if available */
+if (dev->hw_ol_features & NETDEV_TX_VXLAN_TNL_TSO_OFFLOAD) {
+conf.txmode.offloads |= DEV_TX_OFFLOAD_VXLAN_TNL_TSO;
+conf.txmode.offloads |= DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM;
+conf.txmode.offloads |= DEV_TX_OFFLOAD_MULTI_SEGS;
+}
 if (dev->hw_ol_features & NETDEV_TX_SCTP_CHECKSUM_OFFLOAD) {
 conf.txmode.offloads |= DEV_TX_OFFLOAD_SCTP_CKSUM;
 }
@@ -1126,6 +1134,10 @@ dpdk_eth_dev_init(struct netdev_dpdk *dev)
 if ((info.tx_offload_capa & tx_tso_offload_capa)
 == tx_tso_offload_capa) {
 dev->hw_ol_features |= NETDEV_TX_TSO_OFFLOAD;
+/* Enable VXLAN TSO support if available */
+if (info.tx_offload_capa & DEV_TX_OFFLOAD_VXLAN_TNL_TSO) {
+dev->hw_ol_features |= NETDEV_TX_VXLAN_TNL_TSO_OFFLOAD;
+}
 if (info.tx_offload_capa & DEV_TX_OFFLOAD_SCTP_CKSUM) {
 dev->hw_ol_features |= NETDEV_TX_SCTP_CHECKSUM_OFFLOAD;
 } else {
@@ -2131,6 +2143,57 @@ netdev_dpdk_rxq_dealloc(struct netdev_rxq *rxq)
 rte_free(rx);
 }
 
+/* Prepare the packet for VXLAN HWOL.
+ * Return True if the packet is OK to continue. */
+static void
+netdev_dpdk_prep_vxlan_hwol_packet(struct netdev_dpdk *dev, struct rte_mbuf 
*mbuf)
+{
+struct rte_ether_hdr *eth_hdr =
+rte_pktmbuf_mtod(mbuf, struct rte_ether_hdr *);
+struct rte_ipv4_hdr *ip_hdr;
+struct rte_udp_hdr *udp_hdr;
+struct rte_tcp_hdr *tcp_hdr;
+uint16_t orig_tcp_csum;
+
+/* Clean up offload flags from Rx side */
+mbuf->ol_flags &= ~PKT_RX_RSS_HASH;
+
+if ((mbuf->ol_flags & PKT_TX_TUNNEL_VXLAN) == 0) {
+return;
+}
+
+if (mbuf->ol_flags & PKT_TX_IPV4) {
+ip_hdr = (struct rte_ipv4_hdr *)(eth_hdr + 1);
+udp_hdr = (struct rte_udp_hdr *)(ip_hdr + 1);
+
+/* outer IP checksum */
+ip_hdr->hdr_checksum = 0;
+mbuf->ol_flags |= PKT_TX_OUTER_IP_CKSUM;
+mbuf->ol_flags |= PKT_TX_OUTER_IPV4;
+
+/* inner IP checksum */
+mbuf->ol_flags |= PKT_TX_IP_CKSUM;
+ip_hdr = (struct rte_ipv4_hdr *)((uint8_t *)udp_hdr + mbuf->l2_len);
+ip_hdr->hdr_checksum = 0;
+}
+
+if (mbuf->ol_flags & PKT_TX_TCP_SEG || mbuf->ol_flags & PKT_TX_TCP_CKSUM) {
+ip_hdr = (struct rte_ipv4_hdr *)((uint8_t *)rte_pktmbuf_mtod(mbuf, 
struct rte_ether_hdr *) + mbuf->outer_l2_len + mbuf->outer_l3_len + 
mbuf->l2_len);
+tcp_hdr = (struct rte_tcp_hdr *)((uint8_t *)ip_hdr + mbuf->l3_len);
+
+mbuf->ol_flags |= PKT_TX_TCP_CKSUM;
+if (mbuf->ol_flags & PKT_TX_TCP_SEG) {
+//mbuf->tso_segsz = dev->mtu -