Hi Maksim, All of that is related to Time SYNC and I am not that familiar with those workings within the 82599. I would recommend looking through the Time SYNC documentation on how that would work.
Thanks, Alex On 04/24/2014 06:35 AM, Maksim M wrote: > Hi, Alex > In NIC 82599, there is option to generate frequency via sdp(configured > as out) - in data sheet it appears in red in 2.png . That frequency is > determined by FREQOUT0/1 register, as it appears in blue in > 1.png(attached here). I could not understand how that RLV is set. For > example, if I need 1Hz to be out via that sdp. > Thanks for advance, and sorry to bother. > > Regards, Maksim > > ------------------------------------------------------------------------ > From: [email protected] > To: [email protected] > CC: [email protected] > Subject: RE: ixgbe NAPI > Date: Mon, 14 Apr 2014 14:33:37 +0000 > > 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 > > > ------------------------------------------------------------------------------ Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ 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
