No, there are no other queue distribution methods available in 82599.
This is the reason why protocols such as VXLAN use a hash in the source port
for UDP. It allows for queue distribution over hardware that is not aware of
the inner headers.
Thanks,
Alex
From: Maksim M [mailto:[email protected]]
Sent: Monday, April 14, 2014 12:44 AM
To: Duyck, Alexander H
Subject: RE: ixgbe NAPI
Alex,
I understand that the recognition of protocol is critical for all distribution
methods, and all decisions about queue assignment is based on flow parameters.
By default, 82599 uses asymmetric method(the TCP session ends up in different
queues). Using it in asymmetric way we change RSSRK(Toeplitz).
It seems, in case of VPN(for example IPSec) RSS hashing is not applicable
because IP/TCP would be not recognized.
Is there any way to use some distribution method(like RSS) in case of VPN?
Regards, Maksim
________________________________
From: [email protected]<mailto:[email protected]>
To: [email protected]<mailto:[email protected]>
Subject: RE: ixgbe NAPI
Date: Mon, 31 Mar 2014 02:56:17 +0000
The 82599 doesn't support any sort of round-robin only scheme. What you have
listed is pretty much the limits of the hardware for queue selection. The
approach you are mentioning likely wouldn't work as FlowDirector still requires
an identification of protocol and does not work on non-IP or fragmented IP
frames.
Thanks,
Alex
From: Maksim M [mailto:[email protected]]
Sent: Sunday, March 30, 2014 3:48 AM
To: Duyck, Alexander H
Subject: RE: ixgbe NAPI
Alex,
Sorry for disturbing you again.
I have a question concerning multi-queue(INTEL 82599) issue.
All multi-queue schemes(FlowDirector, RSS etc) are based on input(parsed
header values - ip src/dst, ports or tuples).
It means the decision about what queue the packet would be directed is based on
content of the packet header.
Does exist any option to distribute the packet between queues equally(like
round-robin) without being dependent on header content(ip src/dst port etc)?
I had some idea to use FlowDirector with 2-byte tuple anywhere inside first 64
byte of the pkt and use identification field of ip header as input parameter,
but the problem that packets optionally could have vlan tags, therefore offset
would be taken wrongly.
Thanks in advance,
Regards, Maksim
________________________________
From: [email protected]<mailto:[email protected]>
To: [email protected]<mailto:[email protected]>
Subject: RE: ixgbe NAPI
Date: Wed, 5 Feb 2014 10:23:12 +0200
Alex,
It seems that interrupt rate is once in 2 sec, as you pointed.
P.S
I am very grateful for your assistance. Thanks again.
Maksim
> Date: Tue, 4 Feb 2014 08:28:31 -0800
> From: [email protected]<mailto:[email protected]>
> To: [email protected]<mailto:[email protected]>
> CC:
> [email protected]<mailto:[email protected]>
> Subject: Re: ixgbe NAPI
>
> Maksim,
>
> The check_hang_subtask function is only meant to be run once every 2
> seconds. As such you should only be seeing one interrupt per vector
> every 2 seconds. How is this overloading your CPU? Are you seeing the
> interrupts fire at a rate faster than 1 every 2 seconds?
>
> The function is meant to trigger an interrupt every 2 seconds in the
> unlikely event that an interrupt is lost. Without it you may see Tx/Rx
> DMA hangs due to lost interrupts.
>
> Thanks,
>
> Alex
>
> On 02/04/2014 06:54 AM, Maksim M wrote:
> > Alexander,
> > Please, dismiss previous email, it seems, I got it sorted out.
> > According to the 82599, EICS Register enables sw to initiate a
> > hardware interrupt. Setting EICS bit causes interrupt assertion.
> > As you pointed, event service triggers ixgbe_check_hang_subtask(). It
> > calls ixgbe_irq_rearm_queues() that is really doing the job.
> > It overloads CPU in terms of interrupts, therefore in wire-speed rate
> > we see some performance degradation, but from INTEL side it looks
> > indispensable.
> > What side effect could it cause, disabling that interrupt generation
> > and what the reason to strobe interrupts lines?
> >
> > P.S Thanks again and sorry for disturbing!
> > Regards, Maksim
> >
> >
> > ------------------------------------------------------------------------
> > From: [email protected]<mailto:[email protected]>
> > To: [email protected]<mailto:[email protected]>
> > Subject: RE: ixgbe NAPI
> > Date: Tue, 4 Feb 2014 11:10:20 +0200
> >
> > Alexander,
> > Thanks for reply.
> > We get interrupt(irq num) via request_irq(), providing irq handler. It
> > means that it would be generated by the hardware(as I was sure -
> > wrongly , after DMA transaction). Here attached file that depicts
> > interrupt picture of dna interface(it is same as ixgbe, in term of
> > interrupt scheme) -- no packets have been sent/received. All
> > interrupts are increased in the same rate. Also, the file contains
> > stack trace, sampled in IRQ Handler point. It seems, that hardware
> > initiates that interrupt. Looking at service event handler, I try to
> > understand how it could cause hardware to fire interrupt.
> > May be, I misunderstand some point :).
> >
> > P.S
> > Thanks again for assistance!
> >
> > Regards, Maksim
> >
> > > Date: Mon, 3 Feb 2014 09:39:30 -0800
> > > From: [email protected]<mailto:[email protected]>
> > > To: [email protected]<mailto:[email protected]>;
> > > [email protected]<mailto:[email protected]>
> > > Subject: Re: ixgbe NAPI
> > >
> > > On 02/03/2014 08:59 AM, Maksim M wrote:
> > > > Hi, Alexander
> > > >
> > ------------------------------------------------------------------------
> > > >
> > > >
> > > > Recently, I came across some issue with ixgbe drive.
> > > > The matter is following:
> > > > IXGBE is working in NAPI , so I was sure that Rx interrupt was
> > fired for
> > > > first packet in the batch and after that, it works in polling mode(as
> > > > every tutorial explains). That first interrupt delegates the job via
> > > > napi_schedule() to the sofrirq to make polling. But as turned out,
> > > > interrupts is coming without being dependent whether traffic exist or
> > > > not. Polling method is constantly being called by softirq when cpu is
> > > > idle. Trying to debug the issue I see that interrupt is called every
> > > > time even there are no packets(interface is up but no physical
> > > > connection). I tried to check EICR, and the bit responsible for
> > > > particular queue is constantly high. I could not understand what
> > causes
> > > > rx/tx interrupts. Tried to play with throttle rate(EITR), but even
> > it is
> > > > set to zero it still fires interrupt.
> > > >
> > > > P.S
> > > > Sorry to bother and thanks in advance.
> > > >
> > > > Regards, Maksim
> > >
> > > Maksim,
> > >
> > > In order to guarantee the interrupts continue to fire, even in the case
> > > of a dropped interrupt the service event handler also triggers an
> > > interrupt every 2 seconds in addition to checking for a hung Tx ring.
> > > If you check there should be code writing to the EICS register in the
> > > service tast that is triggering the interrupts you are seeing.
> > >
> > > Thanks,
> > >
> > > Alex
>
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
E1000-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
