> -----Original Message----- > From: Harish Patil [mailto:harish.patil at qlogic.com] > Sent: Friday, September 04, 2015 2:08 PM > To: Ananyev, Konstantin; dev at dpdk.org > Cc: Ameen Rahman > Subject: Re: PMD/l3fwd issue > > 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. >
If someone would try to run it with RTE_PKTMBUF_HEADROOM non-aligned on 16B, then probably yes. > > > >> > >> 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? Yep, I'd suggest to verify there is no performance difference and submit a patch.
