> .
> .IP "\fBdpif-netdev/pmd-rxq-rebalance\fR [\fIdp\fR]"
> Reassigns rxqs to pmds in the datapath \fIdp\fR based on their current
> usage.
> +.
> +.IP "\fBdpif-netdev/bond-show\fR [\fIdp\fR]"
> +When "other_config:lb-output-action" is set to "true", the userspace
> datapath
> +handles the
>
> Hi. Thanks for the new version it works fine. In order to speed things
> up I prepared an incremental patch with one bug fix and some changes
> that I think are necessary to keep the code clean. Don't be afraid of
> the patch size, there are very few functional changes, most of other
>
>
> Hi. Thanks for the new version it works fine. In order to speed things
> up I prepared an incremental patch with one bug fix and some changes
> that I think are necessary to keep the code clean. Don't be afraid of
> the patch size, there are very few functional changes, most of other
>
v12->v13:
Addressed comments from Ilya, Eelco and Matteo (offline review).
Fixed issues with the patch found by Matteo during testing.
Rebased to OVS master.
v11->v12:
Addressed most of comments from Ilya and Eelco.
https://mail.openvswitch.org/pipermail/ovs-dev/2020-February/367832.html
Problem:
In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
(using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
"HASH" and "RECIRC" datapath actions. After recirculation, the packet is
forwarded to the bond member port based on 8-bits of the
> >
> > Any thoughts on this? Should I write an equivalent of flow_wc_map() and
> use
> > it in xlate_wc_finish()
> > or we use a stricter version i.e. flow_wildcards_init_for_packet() and
use
> > in revalidate_ukey__?
>
> My big problem for review here is that I don't understand the motivation
>
> > Hi Matteo,
> >
> > Thanks for the patch. But I fail to understand why there is a memory leak.
> > In fact when I tested in my setup, the test ran without any leak.
>
> The main part is:
> '_REFILL_' loop removes packets from the original batch and
> dp_execute_output_action()
> doesn't free
Hi Matteo,
Thanks for the patch. But I fail to understand why there is a memory leak.
In fact when I tested in my setup, the test ran without any leak.
The functions dp_execute_lb_output_action and dp_execute_output_action, both
return 'false' if current batch is non-empty.
case
Problem:
In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
(using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
"HASH" and "RECIRC" datapath actions. After recirculation, the packet is
forwarded to the bond member port based on 8-bits of the
v11->v12:
Addressed most of comments from Ilya and Eelco.
https://mail.openvswitch.org/pipermail/ovs-dev/2020-February/367832.html
https://mail.openvswitch.org/pipermail/ovs-dev/2020-February/367842.html
Rebased to OVS master.
v10->v11:
Addressed Ben and Ilya's comments.
> > Currently fast-failover group does not support checking liveness of
> controller
> > port (OFPP_CONTROLLER). However this feature can be useful for selecting
> > alternate pipeline when controller connection itself is down for e.g.
> > by using local DHCP server to reply for any DHCP request
> > I am inclined to use option 2 to have per-pmd cmap of bonds however,
> > I see that even in this option we will need to have one cmap (or hmap)
> > of bonds at global datapath level. This will take care of
> > reconfigure_pmd_threads
> > scenario. New PMDs needs to be configured with bond cmap
>
> Currently fast-failover group does not support checking liveness of
controller
> port (OFPP_CONTROLLER). However this feature can be useful for selecting
> alternate pipeline when controller connection itself is down for e.g.
> by using local DHCP server to reply for any DHCP request
> To me it looks like we will need an equivalent of flow_wc_map() which is
> less stricter than
> flow_wildcards_init_for_packet() if we want to add this check in
> xlate_wc_finish().
>
> Let me know if the current solution has issues. I can try to move this
check
> to
> xlate_wc_finish()
Problem:
In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
(using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
"HASH" and "RECIRC" datapath actions. After recirculation, the packet is
forwarded to the bond member port based on 8-bits of the
v10->v11:
Addressed Ben and Ilya's comments.
https://mail.openvswitch.org/pipermail/ovs-dev/2020-January/366626.html
https://mail.openvswitch.org/pipermail/ovs-dev/2020-January/367306.html
Using cmap instead of hmap and removed use of bond cache for pmds.
v9->v10:
Rebased to OVS master.
> >
> > So, the root cause of all the issues in this patch, in my understanding,
> > is the fact that you need to collect statistics for all the bond hashes
> > in order to be able to rebalance traffic. This forces you to have access
> > to PMD local caches.
> >
> > The basic idea how to overcome
> Thanks for reviewing the patch. When I use the same fix in
xlate_wc_finish()
> I get several unit test failures: 0738 0756 0763 0768 2247 2251 2255
> 2256.
>
> 0738:
> -Megaflow:
>
recirc_id=0,eth,ip,tun_id=0,tun_src=1.1.1.1,tun_dst=2.2.2.2,tun_tos=3,tun_fl
>
> >
> > Please add an item to NEWS.
> >
> > OVS is currently in "soft freeze" for the next release. We should fork
> > for the next release at the end of the week. Therefore, please resubmit
> > your patch next week.
>
> Thanks Ben. Sure I will post new patch after fork is done.
>
Hi Ben,
I
Currently fast-failover group does not support checking liveness of controller
port (OFPP_CONTROLLER). However this feature can be useful for selecting
alternate pipeline when controller connection itself is down for e.g.
by using local DHCP server to reply for any DHCP request originating from
>
> So, the root cause of all the issues in this patch, in my understanding,
> is the fact that you need to collect statistics for all the bond hashes
> in order to be able to rebalance traffic. This forces you to have access
> to PMD local caches.
>
> The basic idea how to overcome this issue is
> This is clever! I think that this kind of approach is the right one.
>
> I don't yet understand why this should be moved from xlate_wc_finish()
> to revalidate_ukey__(). Can you help me understand that?
Hi Ben,
Thanks for reviewing the patch. When I use the same fix in xlate_wc_finish()
I
> >
> > Thanks for the patch!
> >
> > I have a few minor stylistic suggestions, see below.
> >
> > I'd like to hear Ilya's opinion on this.
>
> Thanks Ben for review! I'll take another look at this patch in a next
> couple of days.
>
> >
Hi Ilya, Ben,
Let me know if you have any comments. Can
The wildcard bits in the installed megaflow entry could be different from
the bits originally generated by the ofproto layer. Datapath implementation
wildcards those match fields which are not present in the incoming packet
before installing the flow.
When the revalidator thread validates a
>
> Thanks for the new feature.
>
> Please add an item to NEWS.
>
> OVS is currently in "soft freeze" for the next release. We should fork
> for the next release at the end of the week. Therefore, please resubmit
> your patch next week.
Thanks Ben. Sure I will post new patch after fork is
Currently fast-failover group does not support checking liveness of controller
port (OFPP_CONTROLLER). However this feature can be useful for selecting
alternate pipeline when controller connection itself is down for e.g.
by using local DHCP server to reply for any DHCP request originating from
Problem:
In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
(using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
"HASH" and "RECIRC" datapath actions. After recirculation, the packet is
forwarded to the bond member port based on 8-bits of the
v9->v10:
Rebased to OVS master.
v8->v9:
Applied Ben's patch for fixing sparse and type errors.
Addressed review comments from Ben.
https://mail.openvswitch.org/pipermail/ovs-dev/2019-December/366101.html
v7->v8:
Removed hash action for balance-tcp mode.
Removed bond-only pmd reload action.
>
> I'm not sure what's happened here but this patch really really fails to
> apply:
>
> Applying: Avoid dp_hash recirculation for balance-tcp bond selection
> mode
> error: patch failed:
> datapath/linux/compat/include/linux/openvswitch.h:994
> error:
v8->v9:
Applied Ben's patch for fixing sparse and type errors.
Addressed review comments from Ben.
https://mail.openvswitch.org/pipermail/ovs-dev/2019-December/366101.html
v7->v8:
Removed hash action for balance-tcp mode.
Removed bond-only pmd reload action.
Rebased to OVS master.
v6->v7:
Problem:
In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
(using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
"HASH" and "RECIRC" datapath actions. After recirculation, the packet is
forwarded to the bond member port based on 8-bits of the
>
> I took a look. The underlying issue is that code here mixes integers,
> ofp_port_t, and odp_port_t. OVS uses "sparse" annotations to keep these
> from being confused, since they are different in important ways. I
> spent some time working through the types here and appended a patch that
>
v7->v8:
Removed hash action for balance-tcp mode.
Removed bond-only pmd reload action.
Rebased to OVS master.
v6->v7:
Fixed issue reported by Matteo for bond/show.
v5->v6:
Addressed comments from Ilya Maximets.
https://mail.openvswitch.org/pipermail/ovs-dev/2019-August/362001.html
Rebased
Problem:
In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
(using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
"HASH" and "RECIRC" datapath actions. After recirculation, the packet is
forwarded to the bond member port based on 8-bits of the
> Thanks, applied to master.
Thanks Ben.
Warm Regards,
Vishal Ajmera
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
When a packet is processed by the slow path and the matching OpenFlow
rule has actions like push_mpls/set_field and push_vlan/set_field, the
ofproto layer un-wildcards the MPLS and VLAN match fields in the megaflow
entry that it plans to install. However, when the megaflow entry is
actually
Hi Darrell, Ben
Sent v2 patch for branch 2.6. It will also apply cleanly to branch 2.7. If
looks ok, kindly merge.
Warm Regards,
Vishal Ajmera
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
From: Darrell Ball
The ICMPv4 error data L4 length check was found to be too strict for TCP,
expecting a minimum of 20 rather than 8 bytes. This worked by
hapenstance for other inner protocols. The approach is to explicitly
handle the ICMPv4 error data L4 length check and to do this for all
>
> Thanks Darrell. I have sent patches for branch 2.8 and 2.9.
> For branches before 2.7 & 2.6 it is giving quite a few conflicts.
> Can you please have a look at it?
>
Hi Darrell, Ben
I have tried manual merge on OVS 2.6 branch and sent a patch.
Can you please review and apply it on branch?
From: Darrell Ball
The ICMPv4 error data L4 length check was found to be too strict for TCP,
expecting a minimum of 20 rather than 8 bytes. This worked by
hapenstance for other inner protocols. The approach is to explicitly
handle the ICMPv4 error data L4 length check and to do this for all
>
> Thanks
> This is eligible to go back to 2.6; it should apply cleanly back to 2.9; I
> can look into the remaining ones,
> unless Vishal would like to do those.
Thanks Darrell. I have sent patches for branch 2.8 and 2.9.
For branches before 2.7 & 2.6 it is giving quite a few conflicts.
Can
From: Darrell Ball
The ICMPv4 error data L4 length check was found to be too strict for TCP,
expecting a minimum of 20 rather than 8 bytes. This worked by
hapenstance for other inner protocols. The approach is to explicitly
handle the ICMPv4 error data L4 length check and to do this for all
From: Darrell Ball
The ICMPv4 error data L4 length check was found to be too strict for TCP,
expecting a minimum of 20 rather than 8 bytes. This worked by
hapenstance for other inner protocols. The approach is to explicitly
handle the ICMPv4 error data L4 length check and to do this for all
> >
> > I'll be able to provide the patches but you will need to test them
> > since I no longer have an
> > environment that will build branches older than 2.8. I'll post
> > patches for 2.8, 2.7 and 2.6
> > in a bit.
>
> The patches are posted Vishal, please test and review.
>
Thanks Greg. I
> > Upstream commit 648700f76b03 ("inet: frags: use rhashtables...") changed
> > how ipv6 fragmentation is implemented. This patch was backported to
> > the upstream stable 4.9.x kernel starting at 4.9.135.
> >
> > This patch creates the compatibility layer changes required to both
> > compile
>
> All unit test passed, plus others I did.
>
> Tested-by: Matteo Croce
>
Thank you Matteo for your efforts in testing this patch.
Warm Regards,
Vishal Ajmera
___
dev mailing list
d...@openvswitch.org
> >
> Let me check this in my setup. I always used 'netdev' bridges for testing my
> patch.
> May be I need to be check for data path support in the display function as
> well.
Hi,
I have sent v7 version of patch fixing this issue.
Warm Regards,
Vishal Ajmera
Problem:
In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
(using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
"HASH" and "RECIRC" datapath actions. After recirculation, the packet is
forwarded to the bond member port based on 8-bits of the
v6->v7:
Fixed issue reported by Matteo for bond/show.
v5->v6:
Addressed comments from Ilya Maximets.
https://mail.openvswitch.org/pipermail/ovs-dev/2019-August/362001.html
Rebased to OVS master.
v4->v5:
Support for stats per hash bucket.
Support for dynamic load balancing.
Rebased to OVS
> >
> > I confirm a decent performance improvement with DPDK and balance-tcp
> bonding:
> >
> > lb-output-action=false
> >
> > rx: 740 Mbps 1446 kpps
> >
> > lb-output-action=true
> >
> > rx: 860 Mbps 1680 kpps
> >
> > I'm running a very simple test with a tweaked version of testpmd which
> >
Problem:
In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
(using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
"HASH" and "RECIRC" datapath actions. After recirculation, the packet is
forwarded to the bond member port based on 8-bits of the
v5->v6:
Addressed comments from Ilya Maximets.
https://mail.openvswitch.org/pipermail/ovs-dev/2019-August/362001.html
Rebased to OVS master.
v4->v5:
Support for stats per hash bucket.
Support for dynamic load balancing.
Rebased to OVS Master.
v3->v4:
Addressed Ilya Maximets comments.
52 matches
Mail list logo
