| Message ID | 20210122224453.4161729-6-vinicius.gomes@intel.com |
|---|---|
| State | Awaiting Upstream |
| Headers | show |
| Series | ethtool: Add support for frame preemption | expand |
On Fri, Jan 22, 2021 at 02:44:50PM -0800, Vinicius Costa Gomes wrote: > Avoid possible TX Hangs caused by using long Qbv cycles. In some > cases, using long cycles (more than 1 second) can cause transmissions > to be blocked for that time. As the TX Hang timeout is close to 1 > second, we may need to reduce the cycle time to something more > reasonable: the value chosen is 1ms. > > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> > --- Don't you want this patch to go to 'net' and be backported?
On Tue Jan 26 2021, Vladimir Oltean wrote: > On Fri, Jan 22, 2021 at 02:44:50PM -0800, Vinicius Costa Gomes wrote: >> Avoid possible TX Hangs caused by using long Qbv cycles. In some >> cases, using long cycles (more than 1 second) can cause transmissions >> to be blocked for that time. As the TX Hang timeout is close to 1 >> second, we may need to reduce the cycle time to something more >> reasonable: the value chosen is 1ms. >> >> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> >> --- > > Don't you want this patch to go to 'net' and be backported? I'm wondering about this patch as well. Is this fix related to frame preemption? If I understand the code correctly the 1sec is a dummy cycle and all queues are open. How should Tx hang then? Thanks, Kurt
Hi, Vladimir Oltean <vladimir.oltean@nxp.com> writes: > On Fri, Jan 22, 2021 at 02:44:50PM -0800, Vinicius Costa Gomes wrote: >> Avoid possible TX Hangs caused by using long Qbv cycles. In some >> cases, using long cycles (more than 1 second) can cause transmissions >> to be blocked for that time. As the TX Hang timeout is close to 1 >> second, we may need to reduce the cycle time to something more >> reasonable: the value chosen is 1ms. >> >> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> >> --- > > Don't you want this patch to go to 'net' and be backported? Will propose this patch to 'net'. Thanks. Cheers,
diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c index 43aec42e6d9d..1ae5f29d1b70 100644 --- a/drivers/net/ethernet/intel/igc/igc_main.c +++ b/drivers/net/ethernet/intel/igc/igc_main.c @@ -4681,12 +4681,12 @@ static int igc_save_launchtime_params(struct igc_adapter *adapter, int queue, if (adapter->base_time) return 0; - adapter->cycle_time = NSEC_PER_SEC; + adapter->cycle_time = NSEC_PER_MSEC; for (i = 0; i < adapter->num_tx_queues; i++) { ring = adapter->tx_ring[i]; ring->start_time = 0; - ring->end_time = NSEC_PER_SEC; + ring->end_time = NSEC_PER_MSEC; } return 0; diff --git a/drivers/net/ethernet/intel/igc/igc_tsn.c b/drivers/net/ethernet/intel/igc/igc_tsn.c index 38451cf05ac6..f5a5527adb21 100644 --- a/drivers/net/ethernet/intel/igc/igc_tsn.c +++ b/drivers/net/ethernet/intel/igc/igc_tsn.c @@ -54,11 +54,11 @@ static int igc_tsn_disable_offload(struct igc_adapter *adapter) wr32(IGC_TXQCTL(i), 0); wr32(IGC_STQT(i), 0); - wr32(IGC_ENDQT(i), NSEC_PER_SEC); + wr32(IGC_ENDQT(i), NSEC_PER_MSEC); } - wr32(IGC_QBVCYCLET_S, NSEC_PER_SEC); - wr32(IGC_QBVCYCLET, NSEC_PER_SEC); + wr32(IGC_QBVCYCLET_S, NSEC_PER_MSEC); + wr32(IGC_QBVCYCLET, NSEC_PER_MSEC); adapter->flags &= ~IGC_FLAG_TSN_QBV_ENABLED;
Avoid possible TX Hangs caused by using long Qbv cycles. In some cases, using long cycles (more than 1 second) can cause transmissions to be blocked for that time. As the TX Hang timeout is close to 1 second, we may need to reduce the cycle time to something more reasonable: the value chosen is 1ms. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> --- drivers/net/ethernet/intel/igc/igc_main.c | 4 ++-- drivers/net/ethernet/intel/igc/igc_tsn.c | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-)