Hi, 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
You can generate frequency outputs on SDP pins, using this feature, however it depends on how you set the TIMINCA register, that determines how fast SYSTIM advanced. There is a limitation on this as well, that any period output of the SDP has to be an exact multiple of twice the internal clock period that drives the TimeSync features. For the 82599, that is documented in the datasheet as 6.4 nanoseconds, which means the minimum period for the SDP output will be 12.8 nanoseconds. In addition, NO period which is not an exact multiple of 12.8 nanoseconds will be able to be generated. You would have to keep that in mind when determining exactly what output frequency you wanted. Generally, the clock works by adding TIMINCA register value to SYSTIME every internal clock tick. It also subtracts the TIMINCA value from the FREQOUT register, storing it in an internal countdown. Once the countdown register reaches 0, it will perform a level change on the SDP. You would have to determine the FREQOUT value as a multiple of TIMINCA for best behavior of a periodic output on the SDP. Regards, Jake On Thu, 2014-04-24 at 07:45 -0700, Alexander Duyck wrote: > 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 ------------------------------------------------------------------------------ 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
