From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Harish Patil <harish.patil@qlogic.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] PMD/l3fwd issue
Date: Fri, 4 Sep 2015 13:19:03 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB97725836A8344F@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <D20EE2D9.BD382%harish.patil@qlogic.com>
> -----Original Message-----
> From: Harish Patil [mailto:harish.patil@qlogic.com]
> Sent: Friday, September 04, 2015 2:08 PM
> To: Ananyev, Konstantin; dev@dpdk.org
> Cc: Ameen Rahman
> Subject: Re: PMD/l3fwd issue
>
> Hi Konstantin,
>
> >Hi Patil,
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Harish Patil
> >> Sent: Thursday, September 03, 2015 4:53 PM
> >> To: dev@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.
From our side we can do some extra performance testing too.
Thanks
Konstantin
>
> >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.
next prev parent reply other threads:[~2015-09-04 13:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-03 15:52 Harish Patil
2015-09-04 12:45 ` Ananyev, Konstantin
2015-09-04 13:07 ` Harish Patil
2015-09-04 13:19 ` Ananyev, Konstantin [this message]
2015-11-07 3:48 ` Harish Patil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2601191342CEEE43887BDE71AB97725836A8344F@irsmsx105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=dev@dpdk.org \
--cc=harish.patil@qlogic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).