[ovs-dev] Is this an issue for DPDK vhost rss?

Daniele Di Proietto diproiettod at vmware.com
Tue Jun 16 18:48:13 UTC 2015



On 16/06/2015 18:27, "Flavio Leitner" <fbl at sysclose.org> wrote:

>On Mon, Jun 15, 2015 at 05:55:13PM +0000, Daniele Di Proietto wrote:
>> On 15/06/2015 12:16, "Traynor, Kevin" <kevin.traynor at intel.com> wrote:
>> >There is a dpdk patchset that contains a potential fix for this and
>>lots
>> >of
>> >other changes, but I haven't tested yet.
>> 
>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_ml_archives
>>>_d
>> 
>>>ev_2015-2DJune_018436.html&d=BQIFAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihV
>>>MN
>> 
>>>tXt-uEs&r=SmB5nZacmXNq0gKCC1s_Cw5yUNjxgD4v5kJqZ2uWLlE&m=FDVPKa2SqwpyYOTm
>>>A2
>> 
>>>zGdscCPa1FVdQG3Zbr4tHrp38&s=fjg7wArWvYLJlgEGKijK6W6ECAxGk660UrPF3rAr4Rs&
>>>e=
>
>I skimmed over the patchset and it is an ABI breaker, so I
>think the policy demands to announce it on 2.1 and merge only
>in 2.2 release.
>
>Maybe it is possible to separate the ol_flags fix into a
>smaller and simple patch to be accepted as bugfix yet in 2.1.

That'd be ideal.

>
>> >> > Otherwise, should we avoid using the vectorized version?
>> >> 
>> >> that's debatable - from a performance view it may be better to leave
>>it
>> >>in
>> >> and take the hit elsewhere for the time being if there's a
>>possibility
>> >>that
>> >> it will be changed in DPDK later.
>> >
>> >With a loop to reset the rss after the rte_vhost_dequeue_burst() call
>>I'm
>> >seeing a drop of ~100kpps in vhost performance. Rx vectoristion gives a
>> >gain
>> >of about ~1 mpps on my system for the phy2phy cases.
>> >
>> >Using the ol_flags check is the right option when DPDK supports
>>setting it
>> >correctly with rx vectorisation. In the meantime there's choice of
>>using
>> >the
>> >reset loop or removing rx vectorisation - what do you think?
>> 
>> Thanks for sharing these results.  I've observed that if OVS can't use
>>the
>> RSS
>> hash and has to compute we lose ~2Mpps on a single flow phy2phy test.
>> 
>> Despite this, I still think we should consider the ol_flags because:
>> 
>> * DPDK drivers (other than ixgbe) should use ol_flags as well to mark
>>the
>>   RSS hash as valid
>> * ixgbe_recv_pkts_vec() will report PKT_RX_RSS_HASH in future releases
>>(the
>>   patch you sent will be effective since DPDK 2.2, right?)
>
>I agree with the above.

I just sent out a patch that uses the approach you suggested. I didn't
modify
dp_packet_get_rss_hash(), because other code relies on that to return a
proper
value (computed by the hardware or the software).

>
>> If the throughput with the non-vector rx routine is higher we can
>>disable
>> the vector rx as a temporary workaround.
>
>Could you point me to the vector and non-vector rx routines?
>I feel like I am missing something.

ixgbe_recv_pkts_vec() in drivers/net/ixgbe/ixgbe_rxtx.c is the vector rx.
There are multiple version of the non-vector rx routine, I believe we used
ixgbe_recv_pkts() in drivers/net/ixgbe/ixgbe_rxtx.c

Thanks

>
>Thanks,
>fbl 
>




More information about the dev mailing list