| Message ID | 20240707125318.3425097-2-faizal.abdul.rahim@linux.intel.com (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | igc bug fixes related to qbv_count usage | expand |
Faizal Rahim <faizal.abdul.rahim@linux.intel.com> writes: > When user issues these cmds: > 1. Either a) or b) > a) mqprio with hardware offload disabled > b) taprio with txtime-assist feature enabled > 2. etf > 3. tc qdisc delete > 4. taprio with base time in the past > > At step 4, qbv_config_change_errors wrongly increased by 1. > > Excerpt from IEEE 802.1Q-2018 8.6.9.3.1: > "If AdminBaseTime specifies a time in the past, and the current schedule > is running, then: Increment ConfigChangeError counter" > > qbv_config_change_errors should only increase if base time is in the past > and no taprio is active. In user perspective, taprio was not active when > first triggered at step 4. However, i225/6 reuses qbv for etf, so qbv is > enabled with a dummy schedule at step 2 where it enters > igc_tsn_enable_offload() and qbv_count got incremented to 1. At step 4, it > enters igc_tsn_enable_offload() again, qbv_count is incremented to 2. > Because taprio is running, tc_setup_type is TC_SETUP_QDISC_ETF and > qbv_count > 1, qbv_config_change_errors value got incremented. > > This issue happens due to reliance on qbv_count field where a non-zero > value indicates that taprio is running. But qbv_count increases > regardless if taprio is triggered by user or by other tsn feature. It does > not align with qbv_config_change_errors expectation where it is only > concerned with taprio triggered by user. > > Fixing this by relocating the qbv_config_change_errors logic to > igc_save_qbv_schedule(), eliminating reliance on qbv_count and its > inaccuracies from i225/6's multiple uses of qbv feature for other TSN > features. > > The new function created: igc_tsn_is_taprio_activated_by_user() uses > taprio_offload_enable field to indicate that the current running taprio > was triggered by user, instead of triggered by non-qbv feature like etf. > > Fixes: ae4fe4698300 ("igc: Add qbv_config_change_errors counter") > Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com> > Reviewed-by: Simon Horman <horms@kernel.org> > --- Looks good: Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Cheers,
On 07/07/2024 15:53, Faizal Rahim wrote: > When user issues these cmds: > 1. Either a) or b) > a) mqprio with hardware offload disabled > b) taprio with txtime-assist feature enabled > 2. etf > 3. tc qdisc delete > 4. taprio with base time in the past > > At step 4, qbv_config_change_errors wrongly increased by 1. > > Excerpt from IEEE 802.1Q-2018 8.6.9.3.1: > "If AdminBaseTime specifies a time in the past, and the current schedule > is running, then: Increment ConfigChangeError counter" > > qbv_config_change_errors should only increase if base time is in the past > and no taprio is active. In user perspective, taprio was not active when > first triggered at step 4. However, i225/6 reuses qbv for etf, so qbv is > enabled with a dummy schedule at step 2 where it enters > igc_tsn_enable_offload() and qbv_count got incremented to 1. At step 4, it > enters igc_tsn_enable_offload() again, qbv_count is incremented to 2. > Because taprio is running, tc_setup_type is TC_SETUP_QDISC_ETF and > qbv_count > 1, qbv_config_change_errors value got incremented. > > This issue happens due to reliance on qbv_count field where a non-zero > value indicates that taprio is running. But qbv_count increases > regardless if taprio is triggered by user or by other tsn feature. It does > not align with qbv_config_change_errors expectation where it is only > concerned with taprio triggered by user. > > Fixing this by relocating the qbv_config_change_errors logic to > igc_save_qbv_schedule(), eliminating reliance on qbv_count and its > inaccuracies from i225/6's multiple uses of qbv feature for other TSN > features. > > The new function created: igc_tsn_is_taprio_activated_by_user() uses > taprio_offload_enable field to indicate that the current running taprio > was triggered by user, instead of triggered by non-qbv feature like etf. > > Fixes: ae4fe4698300 ("igc: Add qbv_config_change_errors counter") > Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com> > Reviewed-by: Simon Horman <horms@kernel.org> > Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> > --- > drivers/net/ethernet/intel/igc/igc_main.c | 8 ++++++-- > drivers/net/ethernet/intel/igc/igc_tsn.c | 16 ++++++++-------- > drivers/net/ethernet/intel/igc/igc_tsn.h | 1 + > 3 files changed, 15 insertions(+), 10 deletions(-) > Tested-by: Mor Bar-Gabay <morx.bar.gabay@intel.com>
diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c index 305e05294a26..0f8a5ad940ec 100644 --- a/drivers/net/ethernet/intel/igc/igc_main.c +++ b/drivers/net/ethernet/intel/igc/igc_main.c @@ -6334,12 +6334,16 @@ static int igc_save_qbv_schedule(struct igc_adapter *adapter, if (!validate_schedule(adapter, qopt)) return -EINVAL; + igc_ptp_read(adapter, &now); + + if (igc_tsn_is_taprio_activated_by_user(adapter) && + is_base_time_past(qopt->base_time, &now)) + adapter->qbv_config_change_errors++; + adapter->cycle_time = qopt->cycle_time; adapter->base_time = qopt->base_time; adapter->taprio_offload_enable = true; - igc_ptp_read(adapter, &now); - for (n = 0; n < qopt->num_entries; n++) { struct tc_taprio_sched_entry *e = &qopt->entries[n]; diff --git a/drivers/net/ethernet/intel/igc/igc_tsn.c b/drivers/net/ethernet/intel/igc/igc_tsn.c index 22cefb1eeedf..f6eaa288926e 100644 --- a/drivers/net/ethernet/intel/igc/igc_tsn.c +++ b/drivers/net/ethernet/intel/igc/igc_tsn.c @@ -78,6 +78,14 @@ void igc_tsn_adjust_txtime_offset(struct igc_adapter *adapter) wr32(IGC_GTXOFFSET, txoffset); } +bool igc_tsn_is_taprio_activated_by_user(struct igc_adapter *adapter) +{ + struct igc_hw *hw = &adapter->hw; + + return (rd32(IGC_BASET_H) || rd32(IGC_BASET_L)) && + adapter->taprio_offload_enable; +} + /* Returns the TSN specific registers to their default values after * the adapter is reset. */ @@ -262,14 +270,6 @@ static int igc_tsn_enable_offload(struct igc_adapter *adapter) s64 n = div64_s64(ktime_sub_ns(systim, base_time), cycle); base_time = ktime_add_ns(base_time, (n + 1) * cycle); - - /* Increase the counter if scheduling into the past while - * Gate Control List (GCL) is running. - */ - if ((rd32(IGC_BASET_H) || rd32(IGC_BASET_L)) && - (adapter->tc_setup_type == TC_SETUP_QDISC_TAPRIO) && - (adapter->qbv_count > 1)) - adapter->qbv_config_change_errors++; } else { if (igc_is_device_id_i226(hw)) { ktime_t adjust_time, expires_time; diff --git a/drivers/net/ethernet/intel/igc/igc_tsn.h b/drivers/net/ethernet/intel/igc/igc_tsn.h index b53e6af560b7..98ec845a86bf 100644 --- a/drivers/net/ethernet/intel/igc/igc_tsn.h +++ b/drivers/net/ethernet/intel/igc/igc_tsn.h @@ -7,5 +7,6 @@ int igc_tsn_offload_apply(struct igc_adapter *adapter); int igc_tsn_reset(struct igc_adapter *adapter); void igc_tsn_adjust_txtime_offset(struct igc_adapter *adapter); +bool igc_tsn_is_taprio_activated_by_user(struct igc_adapter *adapter); #endif /* _IGC_BASE_H */
When user issues these cmds: 1. Either a) or b) a) mqprio with hardware offload disabled b) taprio with txtime-assist feature enabled 2. etf 3. tc qdisc delete 4. taprio with base time in the past At step 4, qbv_config_change_errors wrongly increased by 1. Excerpt from IEEE 802.1Q-2018 8.6.9.3.1: "If AdminBaseTime specifies a time in the past, and the current schedule is running, then: Increment ConfigChangeError counter" qbv_config_change_errors should only increase if base time is in the past and no taprio is active. In user perspective, taprio was not active when first triggered at step 4. However, i225/6 reuses qbv for etf, so qbv is enabled with a dummy schedule at step 2 where it enters igc_tsn_enable_offload() and qbv_count got incremented to 1. At step 4, it enters igc_tsn_enable_offload() again, qbv_count is incremented to 2. Because taprio is running, tc_setup_type is TC_SETUP_QDISC_ETF and qbv_count > 1, qbv_config_change_errors value got incremented. This issue happens due to reliance on qbv_count field where a non-zero value indicates that taprio is running. But qbv_count increases regardless if taprio is triggered by user or by other tsn feature. It does not align with qbv_config_change_errors expectation where it is only concerned with taprio triggered by user. Fixing this by relocating the qbv_config_change_errors logic to igc_save_qbv_schedule(), eliminating reliance on qbv_count and its inaccuracies from i225/6's multiple uses of qbv feature for other TSN features. The new function created: igc_tsn_is_taprio_activated_by_user() uses taprio_offload_enable field to indicate that the current running taprio was triggered by user, instead of triggered by non-qbv feature like etf. Fixes: ae4fe4698300 ("igc: Add qbv_config_change_errors counter") Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com> Reviewed-by: Simon Horman <horms@kernel.org> --- drivers/net/ethernet/intel/igc/igc_main.c | 8 ++++++-- drivers/net/ethernet/intel/igc/igc_tsn.c | 16 ++++++++-------- drivers/net/ethernet/intel/igc/igc_tsn.h | 1 + 3 files changed, 15 insertions(+), 10 deletions(-)