[Intel-wired-lan] fm10k driver - flow control question

[Intel-wired-lan] fm10k driver - flow control question

[Jags N]

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>

[Intel-wired-lan] fm10k driver - flow control question

[Alexander Duyck]

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] fm10k driver - flow control question

[Jags N]

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>

[Intel-wired-lan] fm10k driver - flow control question

[Alexander Duyck]

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

[Intel-wired-lan] fm10k driver - flow control question

[Wyborny, Carolyn]

> -----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

[Intel-wired-lan] fm10k driver - flow control question

[Jags N]

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>

[Intel-wired-lan] fm10k driver - flow control question

[Keller, Jacob E]

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

[Intel-wired-lan] fm10k driver - flow control question

[Keller, Jacob E]

> -----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
 

[Intel-wired-lan] fm10k driver - flow control question

[Jags N]

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>

[Intel-wired-lan] fm10k driver - flow control question

[Keller, Jacob E]

> -----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

[Intel-wired-lan] fm10k driver - flow control question

[Jags N]

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>