> On 14/01/2019 13:33, Ilya Maximets wrote: > > On 14.01.2019 15:51, Ian Stokes wrote: > >> On 1/11/2019 7:37 PM, Ian Stokes wrote: > >>> On 1/11/2019 4:14 PM, Ilya Maximets wrote: > >>>> Nothing significantly changed since the previous versions. > >>>> This patch set effectively breaks following cases if multi-segment > >>>> mbufs enabled: > >>>> > >>> > >>> Hi Ilya, thanks for your feedback. A few queries and clarifications > for discussion below. > >>> > >>> From reading the mail at first I was under the impression that all > these features were being broken by default after applying the patch? > >>> > >>> To clarify, in your testing, after applying these patches, are the use > cases below broken if you are not using multiseg/TSO? (by default these > are disabled). > >>> > >>> The intention of this work, as an experimental feature, would be that > it is disabled by default and will not introduce new regressions to users > who do not enable it. So there would be no impact on a user who does not > wish to enable this and use OVS DPDK as is today. > >>> > >>> The series would be the first steps to enable OVS DPDK to use TSO in > both inter VM and Host to Host environments using DPDK interfaces that > support the feature. Kernel interfaces such as tap devices are not catered > for as of yet. > >>> > >>> The use cases that are catered for are > >>> > >>> - Inter VM communication on the same host using DPDK Interfaces; > >>> - Inter VM communication on different hosts DPDK Interfaces; > >>> - The same two use cases above, but on a VLAN network. > >>> > >>> Again these are the first steps showing TSO in DPDK with multiseg > feature. > >>> > >> > >> Hi all, > >> > >> with code freeze tomorrow I'd like to come to a consensus on this as > there has bee no response to the counter points made below. > > > > Sorry for responses taking so long. I'm just trying to perform some > testing. > > > >> > >> In summary the status of the feature is: > >> > >> It does not cause the usecases outlined below to break while mutltiseg > is disabled (which by default it is disabled). There is no impact to a > user who does not wish to enable the feature. > > > > Disagree. There is a performance impact. I just made some performance > > testing on current master with and without patch-sets applied (mseg > > and TSO) with my usual "PVP with bonded PHY" scenario. And I see 5% > > average performance drop for the 512B UDP packets if multi-segment > > related patches just applied and *not enabled*. Unfortunately, have no > > time for more testing of other cases as you're hurrying me up. > > Hi Ilya, > > Thanks for pointing this out. > > I've run a few performance testings of my own and I can confirm I also see > a slight performance drop (although not as much as ~5.0%, around ~3.0- > 4.0%). > > From my findings this affects normal packets (it doesn't seem to be > noticeable if we're using 1500B sized packets and above). And this is > because of the changes introduced on the recent v13: > - On previous versions I took the approach of modifying > dp_packet_l2_5/l3/l4() so we know the size a caller wants to fetch and can > reason if the header is within the first segment or not; > - In v13 the approach is now to verify when OvS first parses the packet > and sets the layer offsets, in miniflow_extract, if the headers parsed are > within the first mbuf. > > The reason for the change is because the first approach would require a > unreasonable amount of changes (even more so), so that each place calling > dp_packet_l2_3/l3/l4() would pass a size as well. However, the new changes > also come with some additional checks that are taking some additional > cycles. >
Hi All, in light of this I don’t feel the series has had enough testing and reviews for different use cases from across the community.. As such I'm going to hold off committing to master for the 2.11 release. Once more testing and reviews have been completed as well as fixes for performance drops as highlighted above we can consider for master in the future. Ian _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
