DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Chen, Jing D" <jing.d.chen@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: Michael Frasca <michael.frasca@oracle.com>
Subject: Re: [dpdk-dev] [PATCH] fm10k: conditionally disable RSS during device initialization
Date: Thu, 31 Mar 2016 14:15:18 +0000	[thread overview]
Message-ID: <4341B239C0EFF9468EE453F9E9F4604D0446A97F@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <1734643.Kgakri6QQ3@xps13>

Thomas,

We've agreed offline that the patch works without side effect.
Please kindly apply if possible.

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, March 31, 2016 9:57 PM
> To: dev@dpdk.org
> Cc: Michael Frasca <michael.frasca@oracle.com>; Chen, Jing D
> <jing.d.chen@intel.com>
> Subject: Re: [dpdk-dev] [PATCH] fm10k: conditionally disable RSS during
> device initialization
> 
> Please, anyone to confirm that the patch is valid and must be applied?
> This discussion shows some doubts.
> 
> 
> 2016-03-24 13:35, Michael Frasca:
> > Jing,
> >
> > Thanks for your assistance. The experiment that you have built should
> > allow you to observe the bug. In [5], I would expect that queue 0
> > receives roughly 1/4 of the packets that you sending, assuming the
> > input packets have varied IP addresses. Can you measure what % of
> > packets are actually being received in this single queue setup (after first
> running a 4-queue setup)?
> >
> > When trying to running with only one RX queue, the fm10k retains the
> > same RSS hash function and redirection table that was configured from
> > a previous run. As a result, some packets are still being directed to
> > other receive queues. I have confirmed this by polling the queue
> > specific stats, which I retrieved via rte_eth_xstats_get().
> >
> > Looking at fm10k_dev_rss_configure(), one should see that there is no
> > modification of fm10k registers when nb_rx_queues == 1. As far as I
> > can tell, this is the reason that only a certain partition of packets
> > are being receive in a single queue setup (after first running a multi-queue
> configuration).
> >
> > I am unable to access my development environment today, but if you
> > need, I can later craft a patch to l3fwd that shows the measurement of
> > packets received at each queue.
> >
> > Thanks,
> > Mike
> >
> >
> > > On Mar 24, 2016, at 2:40 AM, Chen, Jing D <jing.d.chen@intel.com> wrote:
> > >
> > > Hi, Frasca,
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Michael Frasca [mailto:michael.frasca@oracle.com
> > >> <mailto:michael.frasca@oracle.com>]
> > >> Sent: Wednesday, March 23, 2016 9:43 PM
> > >> To: Chen, Jing D
> > >> Cc: dev@dpdk.org <mailto:dev@dpdk.org>
> > >> Subject: Re: [PATCH] fm10k: conditionally disable RSS during device
> > >> initialization
> > >>
> > >> Hi Jing,
> > >>
> > >> I ran into this issue while trying to run experiments with
> > >> different RSS configurations (no RSS being one cases). It is not
> > >> clear to me that setting this register to zero is the best way to disable
> RSS.
> > >>
> > >> After digging further, I have a theory that I'm having this issues
> > >> because I've only attached my DPDK application to SR-IOV ports. In
> > >> fm10k_dev_dglort_map_configure(), I see that 'RSS Length' is set
> > >> for the DGLORT decoder. However, it appears that this is only
> > >> invoked for physical functions.
> > >>
> > >> Could this be my problem? Is it required that I bind to the
> > >> physical function if I want to properly manipulate RSS?
> > >>
> > >> Thanks,
> > >> Mike
> > >>
> > > I don't know exactly what problem you ran into. I think we needn't
> > > worry about those DGLORT setting when using VF device.
> > >
> > > I've followed steps to use SRIOV device with RSS enabled and
> > > disabled, both are worked well from my side after applying your patch.
> Below is my setup.
> > >
> > > 1. PF with Linux driver "fm10k-next_0.19.3".
> > > 2. DPDK with latest code from master branch, apply your patch.
> > > 3. Use 1 VF device created by kernel driver.
> > > 4. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 --
> config="(0,0,2),(0,1,2),(0,2,3),(0,3,3)""
> > >    with RSS enabled. After sending packets, I can see all 4 queues received
> packets.
> > > 5. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 --
> config="(0,0,2)""
> > >    with RSS disabled. After sending packets, I can see queue 0 received
> packets.
> > >
> > > Can you explain what actual problem is?
> > > We can talk offline.
> >
> 

  reply	other threads:[~2016-03-31 14:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-22 16:58 Michael Frasca
2016-03-23  3:14 ` Chen, Jing D
2016-03-23 13:42   ` Michael Frasca
2016-03-24  6:40     ` Chen, Jing D
2016-03-24 17:35       ` Michael Frasca
2016-03-31 13:57         ` Thomas Monjalon
2016-03-31 14:15           ` Chen, Jing D [this message]
2016-03-31 15:10   ` Thomas Monjalon

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=4341B239C0EFF9468EE453F9E9F4604D0446A97F@shsmsx102.ccr.corp.intel.com \
    --to=jing.d.chen@intel.com \
    --cc=dev@dpdk.org \
    --cc=michael.frasca@oracle.com \
    --cc=thomas.monjalon@6wind.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).