[dts] [PATCH] rx interrupt: Fixed test case

Owen Hilyard ohilyard at iol.unh.edu
Fri Sep 11 22:17:07 CEST 2020


After looking into it, the l3fwd-power tool does not have the capability to
change queue numbers or mappings without restarting. Testpmd currently
lacks the ability (as far as I know) to bind a queue to an lcore. Is this a
feature that would be reasonable to add to testpmd or should I drop work on
this test case? This is turning into quite a time sink and I'm beginning to
think that it would be more beneficial to DTS if I focused on creating the
Flow API test suite rather than trying to make marginal improvements to
this test case.

Owen Hilyard

On Wed, Sep 9, 2020 at 1:58 AM Tu, Lijuan <lijuan.tu at intel.com> wrote:

> Hi Owen,
>
>
>
> Reduce the number of invocations is a good idea, and your design is more
> perfect for a common case. But we still need to consider the boundary, the
> minimum and the maximum queue number. I really suggest we might get a
> random number from the minimum, maximum, and normal queue number, if then
> invocation is reduced, besides boundary checking is covered. Definitely we
> will run test for a long time not only once.
>
>
>
> thanks
>
>
>
> *From:* dts <dts-bounces at dpdk.org> *On Behalf Of * Owen Hilyard
> *Sent:* 2020年9月3日 2:42
> *To:* Ma, LihongX <lihongx.ma at intel.com>
> *Cc:* dts at dpdk.org; Zhang, Yuwei1 <yuwei1.zhang at intel.com>;
> changqingx.wu at intel.com; Xiao, QimaiX <qimaix.xiao at intel.com>; Hunt,
> David <david.hunt at intel.com>; lylavoie at iol.unh.edu
> *Subject:* Re: [dts] [PATCH] rx interrupt: Fixed test case
>
>
>
> Hello
>
> I'm able to see a material difference between what I've suggested and what
> the prior test case did. I was attempting to reduce the number of
> invocations of a pmd during the test, since those invocations are time
> consuming and, from what I measured, made up the majority of the runtime of
> the test. Is there a reason why all queues and port's can't be opened at
> the same time and then ignored until they are needed? The way I re-did the
> configs was designed to create all possible combinations of settings in the
> format that was originally there. Are all 3 invocations of the pmd needed
> or is it possible to merge those and throw out my other changes? Most of my
> changes were done because I was already planning on submitting a patch to
> remove the extra invocations and aren't as important.
>
> Thanks for your help
>
> Owen
>
>
>
> On Tue, Sep 1, 2020 at 10:02 PM Ma, LihongX <lihongx.ma at intel.com> wrote:
>
> Hi, Owen
> I think the change of the plan is not make sense, the case ' PF interrupt
> pmd with different queue' is want to test the interrupt on different queue,
> The original case will test the queue on min number, max number and normal
> number(between minimum and maximum), but your patch will only test one
> situation.
>
>
> Regards,
> Ma,lihong
>
> > -----Original Message-----
> > From: dts <dts-bounces at dpdk.org> On Behalf Of Owen Hilyard
> > Sent: Wednesday, August 26, 2020 11:04 PM
> > To: dts at dpdk.org
> > Cc: Zhang, Yuwei1 <yuwei1.zhang at intel.com>; changqingx.wu at intel.com;
> Xiao,
> > QimaiX <qimaix.xiao at intel.com>; Hunt, David <david.hunt at intel.com>;
> > lylavoie at iol.unh.edu; Owen Hilyard <ohilyard at iol.unh.edu>
> > Subject: [dts] [PATCH] rx interrupt: Fixed test case
> >
> > fixed test case issues with eal params
> > removed extra instances of l3fwd-power
> >
> > Signed-off-by: Owen Hilyard <ohilyard at iol.unh.edu>
> > ---
> >  test_plans/interrupt_pmd_test_plan.rst | 58 +++++++++-----------
> >  tests/TestSuite_interrupt_pmd.py       | 73 ++++++++++++++------------
> >  2 files changed, 64 insertions(+), 67 deletions(-)
> >
> > diff --git a/test_plans/interrupt_pmd_test_plan.rst
> > b/test_plans/interrupt_pmd_test_plan.rst
> > index cb8b2f1..1f8816d 100644
> > --- a/test_plans/interrupt_pmd_test_plan.rst
> > +++ b/test_plans/interrupt_pmd_test_plan.rst
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dts/attachments/20200911/ec7a1502/attachment.html>


More information about the dts mailing list