* [Intel-wired-lan] fm10k driver - flow control question @ 2018-10-09 16:53 Jags N 2018-10-09 17:24 ` Alexander Duyck 0 siblings, 1 reply; 11+ messages in thread From: Jags N @ 2018-10-09 16:53 UTC (permalink / raw) To: intel-wired-lan Hi, In FM10k intel data sheet, I see that the PCIe End Point (PEP) does not support generation of link based flow control or class based/priority based flow control pause frames to prevent Host Congestion. The same behaviour is oberved in dpdk 18.08 fm10k driver, wherein there is no pfc get or set driver functions defined, which I believe is consistent with data sheet. But, in FM10K linux driver ver 0.26.1 (latest), there is code for setting dcb ets, pfc, dcbx. So I am a bit confused as to how the fm10k driver could support pfc if the hardware data sheet does not mention about it. Could someone help me understand or provide any pointers to documents that details what kind of support is present in 0.26.1 with respect to pfc on PEP, and if fm10k can support pfc setting/getting on PEP interface to protect Host Congestion. Regards, Jagdish -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20181009/8d561978/attachment.html> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Intel-wired-lan] fm10k driver - flow control question 2018-10-09 16:53 [Intel-wired-lan] fm10k driver - flow control question Jags N @ 2018-10-09 17:24 ` Alexander Duyck 2018-10-10 13:40 ` Jags N 0 siblings, 1 reply; 11+ messages in thread From: Alexander Duyck @ 2018-10-09 17:24 UTC (permalink / raw) To: intel-wired-lan On Tue, Oct 9, 2018 at 10:12 AM Jags N <jagsnn@gmail.com> wrote: > > Hi, > > In FM10k intel data sheet, I see that the PCIe End Point (PEP) does not support generation of link based flow control or class based/priority based flow control pause frames to prevent Host Congestion. > > The same behaviour is oberved in dpdk 18.08 fm10k driver, wherein there is no pfc get or set driver functions defined, which I believe is consistent with data sheet. > > But, in FM10K linux driver ver 0.26.1 (latest), there is code for setting dcb ets, pfc, dcbx. So I am a bit confused as to how the fm10k driver could support pfc if the hardware data sheet does not mention about it. > > Could someone help me understand or provide any pointers to documents that details what kind of support is present in 0.26.1 with respect to pfc on PEP, and if fm10k can support pfc setting/getting on PEP interface to protect Host Congestion. > > Regards, > Jagdish It has been a little over 4 years since I wrote the driver so my recollection on this could be a bit rusty, but I believe most of the DCB code in the fm10k linux driver is related to configuring queues associated with traffic classes. Also while the part doesn't support PFC from the PCIe End Point it does have a bit called "DROP_ON_EMPTY" in the RXDCTL register of each queue that determines if we just drop the packet or put backpressure on the internal switch if the Rx ring doesn't have available descriptors. I believe that is how the DCB implementation for the Linux driver is configured. Thanks. - Alex ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Intel-wired-lan] fm10k driver - flow control question 2018-10-09 17:24 ` Alexander Duyck @ 2018-10-10 13:40 ` Jags N 2018-10-10 15:26 ` Alexander Duyck 0 siblings, 1 reply; 11+ messages in thread From: Jags N @ 2018-10-10 13:40 UTC (permalink / raw) To: intel-wired-lan Hi Alex, Thank You ! That really helped me understand the scope of the implementation. If I may ask, I see that "PCIE_RXDCTL.DropOnEmpty" if not set, can hold the packet till "PCIE_DMA_CTRL.MaxHoldTime" expires, after which the queue is set to DROP to avoid future time out on this queue. "PCIE_DMA_CTRL.MaxHoldTime" is defined as log2() of maximum waiting time for descriptors to become available.The maximum time is 2^^31 * PCLK. With PCLK at 500 MHz for Gen3.0, would the following calculation be correct : (2^^31 * PCLK) means, 2^^31 * 2ns = 4294967296 ns = 4 sec, is the maximum hold time that the back pressure on the internal switch will be present after which the queue is set to Drop. Appreciate much your kind response. Regards, Jagdish On Tue, Oct 9, 2018 at 10:54 PM Alexander Duyck <alexander.duyck@gmail.com> wrote: > On Tue, Oct 9, 2018 at 10:12 AM Jags N <jagsnn@gmail.com> wrote: > > > > Hi, > > > > In FM10k intel data sheet, I see that the PCIe End Point (PEP) does not > support generation of link based flow control or class based/priority based > flow control pause frames to prevent Host Congestion. > > > > The same behaviour is oberved in dpdk 18.08 fm10k driver, wherein there > is no pfc get or set driver functions defined, which I believe is > consistent with data sheet. > > > > But, in FM10K linux driver ver 0.26.1 (latest), there is code for > setting dcb ets, pfc, dcbx. So I am a bit confused as to how the fm10k > driver could support pfc if the hardware data sheet does not mention about > it. > > > > Could someone help me understand or provide any pointers to documents > that details what kind of support is present in 0.26.1 with respect to pfc > on PEP, and if fm10k can support pfc setting/getting on PEP interface to > protect Host Congestion. > > > > Regards, > > Jagdish > > It has been a little over 4 years since I wrote the driver so my > recollection on this could be a bit rusty, but I believe most of the > DCB code in the fm10k linux driver is related to configuring queues > associated with traffic classes. Also while the part doesn't support > PFC from the PCIe End Point it does have a bit called "DROP_ON_EMPTY" > in the RXDCTL register of each queue that determines if we just drop > the packet or put backpressure on the internal switch if the Rx ring > doesn't have available descriptors. I believe that is how the DCB > implementation for the Linux driver is configured. > > Thanks. > > - Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20181010/5e00e708/attachment.html> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Intel-wired-lan] fm10k driver - flow control question 2018-10-10 13:40 ` Jags N @ 2018-10-10 15:26 ` Alexander Duyck 2018-10-10 15:54 ` Wyborny, Carolyn 0 siblings, 1 reply; 11+ messages in thread From: Alexander Duyck @ 2018-10-10 15:26 UTC (permalink / raw) To: intel-wired-lan Hi Jagdish, I think you have gotten beyond what I can handle from just memory. Hopefully somebody from the networking team can address the rest of the question as I have no recollection of the hold time logic. Thanks. - Alex On Wed, Oct 10, 2018 at 6:40 AM Jags N <jagsnn@gmail.com> wrote: > > Hi Alex, > > Thank You ! That really helped me understand the scope of the implementation. > > If I may ask, I see that "PCIE_RXDCTL.DropOnEmpty" if not set, can hold the packet till "PCIE_DMA_CTRL.MaxHoldTime" expires, after which the queue is set to DROP to avoid future time out on this queue. > > "PCIE_DMA_CTRL.MaxHoldTime" is defined as log2() of maximum waiting time for descriptors to become available.The maximum time is 2^^31 * PCLK. > > With PCLK at 500 MHz for Gen3.0, would the following calculation be correct : > > (2^^31 * PCLK) means, 2^^31 * 2ns = 4294967296 ns = 4 sec, is the maximum hold time that the back pressure on the internal switch will be present after which the queue is set to Drop. > > Appreciate much your kind response. > > Regards, > Jagdish > > On Tue, Oct 9, 2018 at 10:54 PM Alexander Duyck <alexander.duyck@gmail.com> wrote: >> >> On Tue, Oct 9, 2018 at 10:12 AM Jags N <jagsnn@gmail.com> wrote: >> > >> > Hi, >> > >> > In FM10k intel data sheet, I see that the PCIe End Point (PEP) does not support generation of link based flow control or class based/priority based flow control pause frames to prevent Host Congestion. >> > >> > The same behaviour is oberved in dpdk 18.08 fm10k driver, wherein there is no pfc get or set driver functions defined, which I believe is consistent with data sheet. >> > >> > But, in FM10K linux driver ver 0.26.1 (latest), there is code for setting dcb ets, pfc, dcbx. So I am a bit confused as to how the fm10k driver could support pfc if the hardware data sheet does not mention about it. >> > >> > Could someone help me understand or provide any pointers to documents that details what kind of support is present in 0.26.1 with respect to pfc on PEP, and if fm10k can support pfc setting/getting on PEP interface to protect Host Congestion. >> > >> > Regards, >> > Jagdish >> >> It has been a little over 4 years since I wrote the driver so my >> recollection on this could be a bit rusty, but I believe most of the >> DCB code in the fm10k linux driver is related to configuring queues >> associated with traffic classes. Also while the part doesn't support >> PFC from the PCIe End Point it does have a bit called "DROP_ON_EMPTY" >> in the RXDCTL register of each queue that determines if we just drop >> the packet or put backpressure on the internal switch if the Rx ring >> doesn't have available descriptors. I believe that is how the DCB >> implementation for the Linux driver is configured. >> >> Thanks. >> >> - Alex ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Intel-wired-lan] fm10k driver - flow control question 2018-10-10 15:26 ` Alexander Duyck @ 2018-10-10 15:54 ` Wyborny, Carolyn 2018-10-11 5:49 ` Jags N 0 siblings, 1 reply; 11+ messages in thread From: Wyborny, Carolyn @ 2018-10-10 15:54 UTC (permalink / raw) To: intel-wired-lan > -----Original Message----- > From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf > Of Alexander Duyck > Sent: Wednesday, October 10, 2018 8:26 AM > To: jagsnn at gmail.com > Cc: intel-wired-lan at osuosl.org > Subject: Re: [Intel-wired-lan] fm10k driver - flow control question > > Hi Jagdish, > > I think you have gotten beyond what I can handle from just memory. > Hopefully somebody from the networking team can address the rest of > the question as I have no recollection of the hold time logic. Adding Jake explicitly for additional info. Thanks, Carolyn > > Thanks. > > - Alex > > On Wed, Oct 10, 2018 at 6:40 AM Jags N <jagsnn@gmail.com> wrote: > > > > Hi Alex, > > > > Thank You ! That really helped me understand the scope of the > implementation. > > > > If I may ask, I see that "PCIE_RXDCTL.DropOnEmpty" if not set, can hold > the packet till "PCIE_DMA_CTRL.MaxHoldTime" expires, after which the > queue is set to DROP to avoid future time out on this queue. > > > > "PCIE_DMA_CTRL.MaxHoldTime" is defined as log2() of maximum waiting > time for descriptors to become available.The maximum time is 2^^31 * PCLK. > > > > With PCLK at 500 MHz for Gen3.0, would the following calculation be > correct : > > > > (2^^31 * PCLK) means, 2^^31 * 2ns = 4294967296 ns = 4 sec, is the > maximum hold time that the back pressure on the internal switch will be > present after which the queue is set to Drop. > > > > Appreciate much your kind response. > > > > Regards, > > Jagdish > > > > On Tue, Oct 9, 2018 at 10:54 PM Alexander Duyck > <alexander.duyck@gmail.com> wrote: > >> > >> On Tue, Oct 9, 2018 at 10:12 AM Jags N <jagsnn@gmail.com> wrote: > >> > > >> > Hi, > >> > > >> > In FM10k intel data sheet, I see that the PCIe End Point (PEP) does not > support generation of link based flow control or class based/priority based > flow control pause frames to prevent Host Congestion. > >> > > >> > The same behaviour is oberved in dpdk 18.08 fm10k driver, wherein > there is no pfc get or set driver functions defined, which I believe is > consistent with data sheet. > >> > > >> > But, in FM10K linux driver ver 0.26.1 (latest), there is code for setting dcb > ets, pfc, dcbx. So I am a bit confused as to how the fm10k driver could > support pfc if the hardware data sheet does not mention about it. > >> > > >> > Could someone help me understand or provide any pointers to > documents that details what kind of support is present in 0.26.1 with respect > to pfc on PEP, and if fm10k can support pfc setting/getting on PEP interface to > protect Host Congestion. > >> > > >> > Regards, > >> > Jagdish > >> > >> It has been a little over 4 years since I wrote the driver so my > >> recollection on this could be a bit rusty, but I believe most of the > >> DCB code in the fm10k linux driver is related to configuring queues > >> associated with traffic classes. Also while the part doesn't support > >> PFC from the PCIe End Point it does have a bit called "DROP_ON_EMPTY" > >> in the RXDCTL register of each queue that determines if we just drop > >> the packet or put backpressure on the internal switch if the Rx ring > >> doesn't have available descriptors. I believe that is how the DCB > >> implementation for the Linux driver is configured. > >> > >> Thanks. > >> > >> - Alex > _______________________________________________ > Intel-wired-lan mailing list > Intel-wired-lan at osuosl.org > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Intel-wired-lan] fm10k driver - flow control question 2018-10-10 15:54 ` Wyborny, Carolyn @ 2018-10-11 5:49 ` Jags N 2018-10-11 16:31 ` Keller, Jacob E 0 siblings, 1 reply; 11+ messages in thread From: Jags N @ 2018-10-11 5:49 UTC (permalink / raw) To: intel-wired-lan Thanks Alex, Carolyn. Hi Jake, The question I have is on fm10k pcie host interface to control host congestion, "PCIE_RXDCTL.DropOnEmpty" if not set, can hold the packet till "PCIE_DMA_CTRL.MaxHoldTime" expires, after which the queue is set to DROP to avoid future time out on this queue. "PCIE_DMA_CTRL.MaxHoldTime" is defined as log2() of maximum waiting time for descriptors to become available.The maximum time is 2^^31 * PCLK. With PCLK at 500 MHz for Gen3.0, is the following calculation and understanding correct, (2^^31 * PCLK) means, 2^^31 * 2ns = 4294967296 ns = 4 sec, is the maximum hold time that the back pressure on the internal switch will be present after which the queue is set to Drop. Kindly advice. Regards, Jagdish On Wed, Oct 10, 2018 at 9:24 PM Wyborny, Carolyn <carolyn.wyborny@intel.com> wrote: > > -----Original Message----- > > From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On > Behalf > > Of Alexander Duyck > > Sent: Wednesday, October 10, 2018 8:26 AM > > To: jagsnn at gmail.com > > Cc: intel-wired-lan at osuosl.org > > Subject: Re: [Intel-wired-lan] fm10k driver - flow control question > > > > Hi Jagdish, > > > > I think you have gotten beyond what I can handle from just memory. > > Hopefully somebody from the networking team can address the rest of > > the question as I have no recollection of the hold time logic. > > Adding Jake explicitly for additional info. > > Thanks, > > Carolyn > > > > Thanks. > > > > - Alex > > > > On Wed, Oct 10, 2018 at 6:40 AM Jags N <jagsnn@gmail.com> wrote: > > > > > > Hi Alex, > > > > > > Thank You ! That really helped me understand the scope of the > > implementation. > > > > > > If I may ask, I see that "PCIE_RXDCTL.DropOnEmpty" if not set, can > hold > > the packet till "PCIE_DMA_CTRL.MaxHoldTime" expires, after which the > > queue is set to DROP to avoid future time out on this queue. > > > > > > "PCIE_DMA_CTRL.MaxHoldTime" is defined as log2() of maximum waiting > > time for descriptors to become available.The maximum time is 2^^31 * > PCLK. > > > > > > With PCLK at 500 MHz for Gen3.0, would the following calculation be > > correct : > > > > > > (2^^31 * PCLK) means, 2^^31 * 2ns = 4294967296 ns = 4 sec, is the > > maximum hold time that the back pressure on the internal switch will be > > present after which the queue is set to Drop. > > > > > > Appreciate much your kind response. > > > > > > Regards, > > > Jagdish > > > > > > On Tue, Oct 9, 2018 at 10:54 PM Alexander Duyck > > <alexander.duyck@gmail.com> wrote: > > >> > > >> On Tue, Oct 9, 2018 at 10:12 AM Jags N <jagsnn@gmail.com> wrote: > > >> > > > >> > Hi, > > >> > > > >> > In FM10k intel data sheet, I see that the PCIe End Point (PEP) does > not > > support generation of link based flow control or class based/priority > based > > flow control pause frames to prevent Host Congestion. > > >> > > > >> > The same behaviour is oberved in dpdk 18.08 fm10k driver, wherein > > there is no pfc get or set driver functions defined, which I believe is > > consistent with data sheet. > > >> > > > >> > But, in FM10K linux driver ver 0.26.1 (latest), there is code for > setting dcb > > ets, pfc, dcbx. So I am a bit confused as to how the fm10k driver could > > support pfc if the hardware data sheet does not mention about it. > > >> > > > >> > Could someone help me understand or provide any pointers to > > documents that details what kind of support is present in 0.26.1 with > respect > > to pfc on PEP, and if fm10k can support pfc setting/getting on PEP > interface to > > protect Host Congestion. > > >> > > > >> > Regards, > > >> > Jagdish > > >> > > >> It has been a little over 4 years since I wrote the driver so my > > >> recollection on this could be a bit rusty, but I believe most of the > > >> DCB code in the fm10k linux driver is related to configuring queues > > >> associated with traffic classes. Also while the part doesn't support > > >> PFC from the PCIe End Point it does have a bit called "DROP_ON_EMPTY" > > >> in the RXDCTL register of each queue that determines if we just drop > > >> the packet or put backpressure on the internal switch if the Rx ring > > >> doesn't have available descriptors. I believe that is how the DCB > > >> implementation for the Linux driver is configured. > > >> > > >> Thanks. > > >> > > >> - Alex > > _______________________________________________ > > Intel-wired-lan mailing list > > Intel-wired-lan at osuosl.org > > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20181011/6d344cdd/attachment-0001.html> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Intel-wired-lan] fm10k driver - flow control question 2018-10-11 5:49 ` Jags N @ 2018-10-11 16:31 ` Keller, Jacob E 2018-10-11 17:34 ` Keller, Jacob E 0 siblings, 1 reply; 11+ messages in thread From: Keller, Jacob E @ 2018-10-11 16:31 UTC (permalink / raw) To: intel-wired-lan Hi, > -----Original Message----- > From: Jags N [mailto:jagsnn at gmail.com] > Sent: Wednesday, October 10, 2018 10:50 PM > To: Wyborny, Carolyn <carolyn.wyborny@intel.com> > Cc: Alexander Duyck <alexander.duyck@gmail.com>; intel-wired-lan at osuosl.org; > Keller, Jacob E <jacob.e.keller@intel.com> > Subject: Re: [Intel-wired-lan] fm10k driver - flow control question > > Thanks Alex, Carolyn. > > Hi Jake, > > The question I have is on fm10k pcie host interface to control host congestion, > > "PCIE_RXDCTL.DropOnEmpty" if not set, can hold the packet till > "PCIE_DMA_CTRL.MaxHoldTime" expires, after which the queue is set to DROP to > avoid future time out on this queue. > > "PCIE_DMA_CTRL.MaxHoldTime" is defined as log2() of maximum waiting time for > descriptors to become available.The maximum time is 2^^31 * PCLK. > Yes. > With PCLK at 500 MHz for Gen3.0, is the following calculation and understanding > correct, > (2^^31 * PCLK) means, 2^^31 * 2ns = 4294967296 ns = 4 sec, is the maximum hold > time that the back pressure on the internal switch will be present after which the > queue is set to Drop. The 4 second time is correct. > Kindly advice. However, I do not know how this backpressures (if any) to the switch. The RRC has an internal cache of descriptors for which it will hold packets. Eventually these will fill up, even as it waits for Rx descriptors from the host interface software memory. I do not know if the switch internals actually do any "back pressuring" here. I'm going to ask somoene internally who knows the switch part better than I do. I hope to have an answer. > > Regards, > Jagdish > Thanks, Jake ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Intel-wired-lan] fm10k driver - flow control question 2018-10-11 16:31 ` Keller, Jacob E @ 2018-10-11 17:34 ` Keller, Jacob E 2018-10-12 19:19 ` Jags N 0 siblings, 1 reply; 11+ messages in thread From: Keller, Jacob E @ 2018-10-11 17:34 UTC (permalink / raw) To: intel-wired-lan > -----Original Message----- > From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf Of > Keller, Jacob E > Sent: Thursday, October 11, 2018 9:31 AM > To: Jags N <jagsnn@gmail.com>; Wyborny, Carolyn <carolyn.wyborny@intel.com> > Cc: intel-wired-lan at osuosl.org > Subject: Re: [Intel-wired-lan] fm10k driver - flow control question > > Hi, > > > -----Original Message----- > > From: Jags N [mailto:jagsnn at gmail.com] > > Sent: Wednesday, October 10, 2018 10:50 PM > > To: Wyborny, Carolyn <carolyn.wyborny@intel.com> > > Cc: Alexander Duyck <alexander.duyck@gmail.com>; intel-wired-lan at osuosl.org; > > Keller, Jacob E <jacob.e.keller@intel.com> > > Subject: Re: [Intel-wired-lan] fm10k driver - flow control question > > > > Thanks Alex, Carolyn. > > > > Hi Jake, > > > > The question I have is on fm10k pcie host interface to control host congestion, > > > > "PCIE_RXDCTL.DropOnEmpty" if not set, can hold the packet till > > "PCIE_DMA_CTRL.MaxHoldTime" expires, after which the queue is set to DROP to > > avoid future time out on this queue. > > > > "PCIE_DMA_CTRL.MaxHoldTime" is defined as log2() of maximum waiting time for > > descriptors to become available.The maximum time is 2^^31 * PCLK. > > > > Yes. > > > With PCLK at 500 MHz for Gen3.0, is the following calculation and understanding > > correct, > > (2^^31 * PCLK) means, 2^^31 * 2ns = 4294967296 ns = 4 sec, is the maximum hold > > time that the back pressure on the internal switch will be present after which the > > queue is set to Drop. > > The 4 second time is correct. > > > Kindly advice. > > However, I do not know how this backpressures (if any) to the switch. The RRC has an > internal cache of descriptors for which it will hold packets. Eventually these will fill up, > even as it waits for Rx descriptors from the host interface software memory. I do not > know if the switch internals actually do any "back pressuring" here. > > I'm going to ask somoene internally who knows the switch part better than I do. I > hope to have an answer. > > > > > Regards, > > Jagdish > > To follow up on this. I talked to one of the engineers who knows more about the switch hardware. Basically, there is no method to flow control or equivalent between the PEP (host interface) and the switch. Thanks, Jake ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Intel-wired-lan] fm10k driver - flow control question 2018-10-11 17:34 ` Keller, Jacob E @ 2018-10-12 19:19 ` Jags N 2018-10-12 20:32 ` Keller, Jacob E 0 siblings, 1 reply; 11+ messages in thread From: Jags N @ 2018-10-12 19:19 UTC (permalink / raw) To: intel-wired-lan Hi Jake, Thanks much for clarifying. "Basically, there is no method to flow control or equivalent between the PEP (host interface) and the switch". If the above is the case, can an Application on the Host, if able to send Priority Flow Control Pause frames towards the switch, be able to pause the Switch from transmitting frames towards Host ? Regards, Jagdish On Thu, Oct 11, 2018 at 11:05 PM Keller, Jacob E <jacob.e.keller@intel.com> wrote: > > > > -----Original Message----- > > From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On > Behalf Of > > Keller, Jacob E > > Sent: Thursday, October 11, 2018 9:31 AM > > To: Jags N <jagsnn@gmail.com>; Wyborny, Carolyn < > carolyn.wyborny at intel.com> > > Cc: intel-wired-lan at osuosl.org > > Subject: Re: [Intel-wired-lan] fm10k driver - flow control question > > > > Hi, > > > > > -----Original Message----- > > > From: Jags N [mailto:jagsnn at gmail.com] > > > Sent: Wednesday, October 10, 2018 10:50 PM > > > To: Wyborny, Carolyn <carolyn.wyborny@intel.com> > > > Cc: Alexander Duyck <alexander.duyck@gmail.com>; > intel-wired-lan at osuosl.org; > > > Keller, Jacob E <jacob.e.keller@intel.com> > > > Subject: Re: [Intel-wired-lan] fm10k driver - flow control question > > > > > > Thanks Alex, Carolyn. > > > > > > Hi Jake, > > > > > > The question I have is on fm10k pcie host interface to control host > congestion, > > > > > > "PCIE_RXDCTL.DropOnEmpty" if not set, can hold the packet till > > > "PCIE_DMA_CTRL.MaxHoldTime" expires, after which the queue is set to > DROP to > > > avoid future time out on this queue. > > > > > > "PCIE_DMA_CTRL.MaxHoldTime" is defined as log2() of maximum waiting > time for > > > descriptors to become available.The maximum time is 2^^31 * PCLK. > > > > > > > Yes. > > > > > With PCLK at 500 MHz for Gen3.0, is the following calculation and > understanding > > > correct, > > > (2^^31 * PCLK) means, 2^^31 * 2ns = 4294967296 ns = 4 sec, is the > maximum hold > > > time that the back pressure on the internal switch will be present > after which the > > > queue is set to Drop. > > > > The 4 second time is correct. > > > > > Kindly advice. > > > > However, I do not know how this backpressures (if any) to the switch. > The RRC has an > > internal cache of descriptors for which it will hold packets. Eventually > these will fill up, > > even as it waits for Rx descriptors from the host interface software > memory. I do not > > know if the switch internals actually do any "back pressuring" here. > > > > I'm going to ask somoene internally who knows the switch part better > than I do. I > > hope to have an answer. > > > > > > > > Regards, > > > Jagdish > > > > > To follow up on this. I talked to one of the engineers who knows more > about the switch hardware. Basically, there is no method to flow control or > equivalent between the PEP (host interface) and the switch. > > Thanks, > Jake > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20181013/5ce31338/attachment-0001.html> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Intel-wired-lan] fm10k driver - flow control question 2018-10-12 19:19 ` Jags N @ 2018-10-12 20:32 ` Keller, Jacob E 2018-10-13 2:50 ` Jags N 0 siblings, 1 reply; 11+ messages in thread From: Keller, Jacob E @ 2018-10-12 20:32 UTC (permalink / raw) To: intel-wired-lan > -----Original Message----- > From: Jags N [mailto:jagsnn at gmail.com] > Sent: Friday, October 12, 2018 12:19 PM > To: Keller, Jacob E <jacob.e.keller@intel.com> > Cc: Wyborny, Carolyn <carolyn.wyborny@intel.com>; intel-wired-lan at osuosl.org > Subject: Re: [Intel-wired-lan] fm10k driver - flow control question > > Hi Jake, > > Thanks much for clarifying. > > "Basically, there is no method to flow control or equivalent between the PEP (host > interface) and the switch". > > If the above is the case, can an Application on the Host, if able to send Priority Flow > Control Pause frames towards the switch, be able to pause the Switch from > transmitting frames towards Host ? > > Regards, > Jagdish > > As far as I understand it, the switch does not honor flow control frames coming from the host interface. The host interface supports receiving class based PAUSE frames from the switch, but as far as I am able to determine, the switch does not handle port based or class based flow control frames from the host interface. So, the answer to this question is "no, that's not supported" Thanks, Jake ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Intel-wired-lan] fm10k driver - flow control question 2018-10-12 20:32 ` Keller, Jacob E @ 2018-10-13 2:50 ` Jags N 0 siblings, 0 replies; 11+ messages in thread From: Jags N @ 2018-10-13 2:50 UTC (permalink / raw) To: intel-wired-lan Thanks Jake. That clarifies. Appreciate much ! Regards, Jagdish On Sat, Oct 13, 2018 at 2:02 AM Keller, Jacob E <jacob.e.keller@intel.com> wrote: > > > > -----Original Message----- > > From: Jags N [mailto:jagsnn at gmail.com] > > Sent: Friday, October 12, 2018 12:19 PM > > To: Keller, Jacob E <jacob.e.keller@intel.com> > > Cc: Wyborny, Carolyn <carolyn.wyborny@intel.com>; > intel-wired-lan at osuosl.org > > Subject: Re: [Intel-wired-lan] fm10k driver - flow control question > > > > Hi Jake, > > > > Thanks much for clarifying. > > > > "Basically, there is no method to flow control or equivalent between the > PEP (host > > interface) and the switch". > > > > If the above is the case, can an Application on the Host, if able to > send Priority Flow > > Control Pause frames towards the switch, be able to pause the Switch from > > transmitting frames towards Host ? > > > > Regards, > > Jagdish > > > > > > As far as I understand it, the switch does not honor flow control frames > coming from the host interface. The host interface supports receiving class > based PAUSE frames from the switch, but as far as I am able to determine, > the switch does not handle port based or class based flow control frames > from the host interface. > > So, the answer to this question is "no, that's not supported" > > Thanks, > Jake > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20181013/5eb904c5/attachment.html> ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-10-13 2:50 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-10-09 16:53 [Intel-wired-lan] fm10k driver - flow control question Jags N 2018-10-09 17:24 ` Alexander Duyck 2018-10-10 13:40 ` Jags N 2018-10-10 15:26 ` Alexander Duyck 2018-10-10 15:54 ` Wyborny, Carolyn 2018-10-11 5:49 ` Jags N 2018-10-11 16:31 ` Keller, Jacob E 2018-10-11 17:34 ` Keller, Jacob E 2018-10-12 19:19 ` Jags N 2018-10-12 20:32 ` Keller, Jacob E 2018-10-13 2:50 ` Jags N
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.