From: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>
To: Zoltan Kiss <zoltan.kiss@linaro.org>,
"Wu, Jingjing" <jingjing.wu@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] ixgbe TX function selection
Date: Fri, 18 Mar 2016 00:45:01 +0000 [thread overview]
Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC09090343C5C9@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <56EAE521.900@linaro.org>
Hi Zoltan,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zoltan Kiss
> Sent: Friday, March 18, 2016 1:11 AM
> To: Wu, Jingjing; dev@dpdk.org
> Subject: Re: [dpdk-dev] ixgbe TX function selection
>
>
>
> On 10/03/16 07:51, Wu, Jingjing wrote:
> > Hi, Zoltan
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zoltan Kiss
> >> Sent: Wednesday, March 2, 2016 3:19 AM
> >> To: dev@dpdk.org
> >> Subject: [dpdk-dev] ixgbe TX function selection
> >>
> >> Hi,
> >>
> >> I've noticed that ixgbe_set_tx_function() selects the non-SG function
> >> even if (dev->data->scattered_rx == 1). That seems a bit dangerous,
> >> as you can turn that on inadvertently when you don't set
> >> max_rx_pkt_len and buffer size in certain ways. I've learnt it in the
> >> hard way, as my segmented packets were leaking memory on the TX path,
> >> which doesn't cries if you send out segmented packets.
> >> How should this case be treated? Assert on the non-SG TX side for the
> >> 'next' pointer? Or turning on SG if RX has it? It doesn't seem to be
> >> a solid way as other interfaces still can have SG turned on.
> >>
> >
> > If you look into the ixgbe_set_tx_function, you will find tx function
> > selection is decided by the tx_flags on queue configure, which is
> > passed by rte_eth_txconf. So even you set dev->data->scattered_rx to
> > 1, if the tx_flags is ETH_TXQ_FLAGS_NOMULTSEGS, ixgbe_xmit_pkts_simple
> > is still selected as tx function. So, you'd better to set tx_flags=0, and have a try.
>
> You mean getting default_txconf from rte_eth_dev_info_get() and explicitly turn
> ETH_TXQ_FLAGS_NOMULTSEGS to 0? (filling tx_flags with zeros doesn't work
> very well) That's a way to solve it for me, but I'm rather talking about using
> defaults which doesn't cause memory leak quite easily.
Yes, ETH_TXQ_FLAGS_NOMULTSEGS only can be set to 1 when you know all your packets will not be segmented.
I think that means normally we should use full function path for TX, for we have no knowledge about if the packets will be segmented or not.
You don't need to set tx_flags to 0, only the ETH_TXQ_FLAGS_NOMULTSEGS bit should be 0, the other bits can be 1 if needed.
>
> >
> >> Regards,
> >>
> >> Zoltan
next prev parent reply other threads:[~2016-03-18 0:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-01 19:18 Zoltan Kiss
2016-03-04 1:47 ` Lu, Wenzhuo
2016-03-04 11:59 ` Zoltan Kiss
2016-03-10 7:51 ` Wu, Jingjing
2016-03-17 17:10 ` Zoltan Kiss
2016-03-18 0:45 ` Lu, Wenzhuo [this message]
2016-03-18 13:33 ` Zoltan Kiss
2016-03-19 15:46 ` Ananyev, Konstantin
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=6A0DE07E22DDAD4C9103DF62FEBC09090343C5C9@shsmsx102.ccr.corp.intel.com \
--to=wenzhuo.lu@intel.com \
--cc=dev@dpdk.org \
--cc=jingjing.wu@intel.com \
--cc=zoltan.kiss@linaro.org \
/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).