[dpdk-dev] PMD/l3fwd issue

[Harish Patil]

Hi Konstantin,

>Hi Patil,
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Harish Patil
>> Sent: Thursday, September 03, 2015 4:53 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] PMD/l3fwd issue
>>
>> Hello,
>> Have a question regarding l3fwd application. The l3fwd application
>>expects
>> the poll mode driver to return packets whose L2 header is 16-byte
>>aligned.
>
>Yep, and as I remember, by default PMD returns ti the upper layer mbufs
>with data offsets
>aligned to cahce line size (64B).
>Unless you'll change RTE_PKTMBUF_HEADROOM config parameter.
>
>> Otherwise, it results in a crash. This is due to use of _mm_load_si128()
>> and _mm_store_si128() intrinsics which expects the address to be 16-byte
>> aligned. However, most of the real protocol stack expects packets such
>> that its IP header be aligned on a 16-byte boundary (not L2). Its not
>>just
>> for IP but any L3 for that matter.  That’s way we usually see
>> skb_reserve(skb, NET_IP_ALIGN) calls in linux drivers.
>
>Well, l3fwd is just an example application to demonstrate usage of DPDK
>API
>And max performance it could get for that type of workload.
>No-one forces you to use aligned load/store in your own application.

Yes, I agree if its our private application. But l3fwd being widely used
as a benchmarking/testing tool and they may ran into this issue.

>
>>
>> So I’m looking for suggestions here, whether l3wd application or poll
>>mode
>> driver should be changed to fix that? What is the right thing to do?
>> Can a check be added in l3fwd to use _mm_loadu_si128/_mm_storeu_si128
>> instructions instead of mm_load_si128/_mm_store_si128 if address is
>>found
>> not be 16B aligned?
>
>I'd personally just change l3fwd to use to use
>_mm_loadu_si128/_mm_storeu_si128 unconditionally.
>As by default  address is 16B aligned anyway, I think that using MOVDQU
>instead of MOVDQA here
>shouldn't make that big difference.
>But off course testing need to be done to make sure there is no
>performance drop with that change.

I too would just change l3fwd application so that all poll mode drivers
would just work. Are you proposing that we upstream l3fwd change if we
don’t see performance drop?

>Konstantin
>
>>
>> Thanks,
>> Harish
>>
>>
>>
>> ________________________________
>>
>> This message and any attached documents contain information from the
>>sending company or its parent company(s), subsidiaries,
>> divisions or branch offices that may be confidential. If you are not
>>the intended recipient, you may not read, copy, distribute, or use
>> this information. If you have received this transmission in error,
>>please notify the sender immediately by reply e-mail and then delete
>> this message.
>



________________________________

This message and any attached documents contain information from the sending company or its parent company(s), subsidiaries, divisions or branch offices that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.