| Message ID | 20240707125318.3425097-3-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: > Following the "igc: Fix TX Hang issue when QBV Gate is close" changes, > remaining issues with the reset adapter logic in igc_tsn_offload_apply() > have been observed: > > 1. The reset adapter logics for i225 and i226 differ, although they should > be the same according to the guidelines in I225/6 HW Design Section > 7.5.2.1 on software initialization during tx mode changes. > 2. The i225 resets adapter every time, even though tx mode doesn't change. > This occurs solely based on the condition igc_is_device_id_i225() when > calling schedule_work(). > 3. i226 doesn't reset adapter for tsn->legacy tx mode changes. It only > resets adapter for legacy->tsn tx mode transitions. > 4. qbv_count introduced in the patch is actually not needed; in this > context, a non-zero value of qbv_count is used to indicate if tx mode > was unconditionally set to tsn in igc_tsn_enable_offload(). This could > be replaced by checking the existing register > IGC_TQAVCTRL_TRANSMIT_MODE_TSN bit. > > This patch resolves all issues and enters schedule_work() to reset the > adapter only when changing tx mode. It also removes reliance on qbv_count. > > qbv_count field will be removed in a future patch. > > Test ran: > > 1. Verify reset adapter behaviour in i225/6: > a) Enrol a new GCL > Reset adapter observed (tx mode change legacy->tsn) > b) Enrol a new GCL without deleting qdisc > No reset adapter observed (tx mode remain tsn->tsn) > c) Delete qdisc > Reset adapter observed (tx mode change tsn->legacy) > > 2. Tested scenario from "igc: Fix TX Hang issue when QBV Gate is closed" > to confirm it remains resolved. > > Fixes: 175c241288c0 ("igc: Fix TX Hang issue when QBV Gate is closed") > Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com> > Reviewed-by: Simon Horman <horms@kernel.org> > --- There were a quite a few bugs, some of them my fault, on this part of the code, changing between the modes in the hardware. So I would like some confirmation that ETF offloading/LaunchTime was also tested with this change. Just to be sure. But code-wise, looks good: Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Cheers,
Hi Vinicius, On 11/7/2024 6:44 am, Vinicius Costa Gomes wrote: > Faizal Rahim <faizal.abdul.rahim@linux.intel.com> writes: > >> Following the "igc: Fix TX Hang issue when QBV Gate is close" changes, >> remaining issues with the reset adapter logic in igc_tsn_offload_apply() >> have been observed: >> >> 1. The reset adapter logics for i225 and i226 differ, although they should >> be the same according to the guidelines in I225/6 HW Design Section >> 7.5.2.1 on software initialization during tx mode changes. >> 2. The i225 resets adapter every time, even though tx mode doesn't change. >> This occurs solely based on the condition igc_is_device_id_i225() when >> calling schedule_work(). >> 3. i226 doesn't reset adapter for tsn->legacy tx mode changes. It only >> resets adapter for legacy->tsn tx mode transitions. >> 4. qbv_count introduced in the patch is actually not needed; in this >> context, a non-zero value of qbv_count is used to indicate if tx mode >> was unconditionally set to tsn in igc_tsn_enable_offload(). This could >> be replaced by checking the existing register >> IGC_TQAVCTRL_TRANSMIT_MODE_TSN bit. >> >> This patch resolves all issues and enters schedule_work() to reset the >> adapter only when changing tx mode. It also removes reliance on qbv_count. >> >> qbv_count field will be removed in a future patch. >> >> Test ran: >> >> 1. Verify reset adapter behaviour in i225/6: >> a) Enrol a new GCL >> Reset adapter observed (tx mode change legacy->tsn) >> b) Enrol a new GCL without deleting qdisc >> No reset adapter observed (tx mode remain tsn->tsn) >> c) Delete qdisc >> Reset adapter observed (tx mode change tsn->legacy) >> >> 2. Tested scenario from "igc: Fix TX Hang issue when QBV Gate is closed" >> to confirm it remains resolved. >> >> Fixes: 175c241288c0 ("igc: Fix TX Hang issue when QBV Gate is closed") >> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com> >> Reviewed-by: Simon Horman <horms@kernel.org> >> --- > > There were a quite a few bugs, some of them my fault, on this part of > the code, changing between the modes in the hardware. > > So I would like some confirmation that ETF offloading/LaunchTime was > also tested with this change. Just to be sure. > > But code-wise, looks good: > > Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> > > > Cheers, Tested etf with offload, looks like working correctly. 1. mqprio tc qdisc add dev enp1s0 handle 100: parent root mqprio num_tc 3 \ map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \ queues 1@0 1@1 2@2 \ hw 0 No reset adapter observed. 2. etf with offload tc qdisc replace dev enp1s0 parent 100:1 etf \ clockid CLOCK_TAI delta 300000 offload Reset adapter observed (tx mode legacy -> tsn). 3. delete qdisc tc qdisc delete dev enp1s0 parent root handle 100 Reset adapter observed (tx mode tsn -> legacy).
"Abdul Rahim, Faizal" <faizal.abdul.rahim@linux.intel.com> writes: > Hi Vinicius, > > On 11/7/2024 6:44 am, Vinicius Costa Gomes wrote: >> Faizal Rahim <faizal.abdul.rahim@linux.intel.com> writes: >> >>> Following the "igc: Fix TX Hang issue when QBV Gate is close" changes, >>> remaining issues with the reset adapter logic in igc_tsn_offload_apply() >>> have been observed: >>> >>> 1. The reset adapter logics for i225 and i226 differ, although they should >>> be the same according to the guidelines in I225/6 HW Design Section >>> 7.5.2.1 on software initialization during tx mode changes. >>> 2. The i225 resets adapter every time, even though tx mode doesn't change. >>> This occurs solely based on the condition igc_is_device_id_i225() when >>> calling schedule_work(). >>> 3. i226 doesn't reset adapter for tsn->legacy tx mode changes. It only >>> resets adapter for legacy->tsn tx mode transitions. >>> 4. qbv_count introduced in the patch is actually not needed; in this >>> context, a non-zero value of qbv_count is used to indicate if tx mode >>> was unconditionally set to tsn in igc_tsn_enable_offload(). This could >>> be replaced by checking the existing register >>> IGC_TQAVCTRL_TRANSMIT_MODE_TSN bit. >>> >>> This patch resolves all issues and enters schedule_work() to reset the >>> adapter only when changing tx mode. It also removes reliance on qbv_count. >>> >>> qbv_count field will be removed in a future patch. >>> >>> Test ran: >>> >>> 1. Verify reset adapter behaviour in i225/6: >>> a) Enrol a new GCL >>> Reset adapter observed (tx mode change legacy->tsn) >>> b) Enrol a new GCL without deleting qdisc >>> No reset adapter observed (tx mode remain tsn->tsn) >>> c) Delete qdisc >>> Reset adapter observed (tx mode change tsn->legacy) >>> >>> 2. Tested scenario from "igc: Fix TX Hang issue when QBV Gate is closed" >>> to confirm it remains resolved. >>> >>> Fixes: 175c241288c0 ("igc: Fix TX Hang issue when QBV Gate is closed") >>> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com> >>> Reviewed-by: Simon Horman <horms@kernel.org> >>> --- >> >> There were a quite a few bugs, some of them my fault, on this part of >> the code, changing between the modes in the hardware. >> >> So I would like some confirmation that ETF offloading/LaunchTime was >> also tested with this change. Just to be sure. >> >> But code-wise, looks good: >> >> Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> >> >> >> Cheers, > > > Tested etf with offload, looks like working correctly. > > 1. mqprio > tc qdisc add dev enp1s0 handle 100: parent root mqprio num_tc 3 \ > map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \ > queues 1@0 1@1 2@2 \ > hw 0 > > No reset adapter observed. > > 2. etf with offload > tc qdisc replace dev enp1s0 parent 100:1 etf \ > clockid CLOCK_TAI delta 300000 offload > > Reset adapter observed (tx mode legacy -> tsn). > > 3. delete qdisc > tc qdisc delete dev enp1s0 parent root handle 100 > > Reset adapter observed (tx mode tsn -> legacy). > That no unexpected resets are happening, is good. But what I had in mind was some functional tests that ETF is working. I guess that's the only way of knowing that it's still working. Sorry that I wasn't clear about that. Cheers,
On 12/7/2024 1:10 am, Vinicius Costa Gomes wrote: > "Abdul Rahim, Faizal" <faizal.abdul.rahim@linux.intel.com> writes: > >> Hi Vinicius, >> >> On 11/7/2024 6:44 am, Vinicius Costa Gomes wrote: >>> Faizal Rahim <faizal.abdul.rahim@linux.intel.com> writes: >>> >>>> Following the "igc: Fix TX Hang issue when QBV Gate is close" changes, >>>> remaining issues with the reset adapter logic in igc_tsn_offload_apply() >>>> have been observed: >>>> >>>> 1. The reset adapter logics for i225 and i226 differ, although they should >>>> be the same according to the guidelines in I225/6 HW Design Section >>>> 7.5.2.1 on software initialization during tx mode changes. >>>> 2. The i225 resets adapter every time, even though tx mode doesn't change. >>>> This occurs solely based on the condition igc_is_device_id_i225() when >>>> calling schedule_work(). >>>> 3. i226 doesn't reset adapter for tsn->legacy tx mode changes. It only >>>> resets adapter for legacy->tsn tx mode transitions. >>>> 4. qbv_count introduced in the patch is actually not needed; in this >>>> context, a non-zero value of qbv_count is used to indicate if tx mode >>>> was unconditionally set to tsn in igc_tsn_enable_offload(). This could >>>> be replaced by checking the existing register >>>> IGC_TQAVCTRL_TRANSMIT_MODE_TSN bit. >>>> >>>> This patch resolves all issues and enters schedule_work() to reset the >>>> adapter only when changing tx mode. It also removes reliance on qbv_count. >>>> >>>> qbv_count field will be removed in a future patch. >>>> >>>> Test ran: >>>> >>>> 1. Verify reset adapter behaviour in i225/6: >>>> a) Enrol a new GCL >>>> Reset adapter observed (tx mode change legacy->tsn) >>>> b) Enrol a new GCL without deleting qdisc >>>> No reset adapter observed (tx mode remain tsn->tsn) >>>> c) Delete qdisc >>>> Reset adapter observed (tx mode change tsn->legacy) >>>> >>>> 2. Tested scenario from "igc: Fix TX Hang issue when QBV Gate is closed" >>>> to confirm it remains resolved. >>>> >>>> Fixes: 175c241288c0 ("igc: Fix TX Hang issue when QBV Gate is closed") >>>> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com> >>>> Reviewed-by: Simon Horman <horms@kernel.org> >>>> --- >>> >>> There were a quite a few bugs, some of them my fault, on this part of >>> the code, changing between the modes in the hardware. >>> >>> So I would like some confirmation that ETF offloading/LaunchTime was >>> also tested with this change. Just to be sure. >>> >>> But code-wise, looks good: >>> >>> Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> >>> >>> >>> Cheers, >> >> >> Tested etf with offload, looks like working correctly. >> >> 1. mqprio >> tc qdisc add dev enp1s0 handle 100: parent root mqprio num_tc 3 \ >> map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \ >> queues 1@0 1@1 2@2 \ >> hw 0 >> >> No reset adapter observed. >> >> 2. etf with offload >> tc qdisc replace dev enp1s0 parent 100:1 etf \ >> clockid CLOCK_TAI delta 300000 offload >> >> Reset adapter observed (tx mode legacy -> tsn). >> >> 3. delete qdisc >> tc qdisc delete dev enp1s0 parent root handle 100 >> >> Reset adapter observed (tx mode tsn -> legacy). >> > > That no unexpected resets are happening, is good. > > But what I had in mind was some functional tests that ETF is working. I > guess that's the only way of knowing that it's still working. Sorry that > I wasn't clear about that. > > > Cheers, My bad. Just tested ETF functionality and it is working. 1. On Tx Board a) mqprio tc qdisc add dev enp1s0 handle 100: parent root mqprio num_tc 3 \ map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \ queues 1@0 1@1 2@2 \ hw 0 b) etf with offload tc qdisc replace dev enp1s0 parent 100:1 etf \ clockid CLOCK_TAI delta 300000 offload c) use UDP TAI app to send packets where tx timestamp is set to current_time + 1ms for each packet. 2. On Rx Board a) Checked .pcap log. Observed that interval duration between each rx packet is 1ms Thanks for your help.
Hi, "Abdul Rahim, Faizal" <faizal.abdul.rahim@linux.intel.com> writes: > On 12/7/2024 1:10 am, Vinicius Costa Gomes wrote: >> "Abdul Rahim, Faizal" <faizal.abdul.rahim@linux.intel.com> writes: >> >>> Hi Vinicius, >>> >>> On 11/7/2024 6:44 am, Vinicius Costa Gomes wrote: >>>> Faizal Rahim <faizal.abdul.rahim@linux.intel.com> writes: >>>> >>>>> Following the "igc: Fix TX Hang issue when QBV Gate is close" changes, >>>>> remaining issues with the reset adapter logic in igc_tsn_offload_apply() >>>>> have been observed: >>>>> >>>>> 1. The reset adapter logics for i225 and i226 differ, although they should >>>>> be the same according to the guidelines in I225/6 HW Design Section >>>>> 7.5.2.1 on software initialization during tx mode changes. >>>>> 2. The i225 resets adapter every time, even though tx mode doesn't change. >>>>> This occurs solely based on the condition igc_is_device_id_i225() when >>>>> calling schedule_work(). >>>>> 3. i226 doesn't reset adapter for tsn->legacy tx mode changes. It only >>>>> resets adapter for legacy->tsn tx mode transitions. >>>>> 4. qbv_count introduced in the patch is actually not needed; in this >>>>> context, a non-zero value of qbv_count is used to indicate if tx mode >>>>> was unconditionally set to tsn in igc_tsn_enable_offload(). This could >>>>> be replaced by checking the existing register >>>>> IGC_TQAVCTRL_TRANSMIT_MODE_TSN bit. >>>>> >>>>> This patch resolves all issues and enters schedule_work() to reset the >>>>> adapter only when changing tx mode. It also removes reliance on qbv_count. >>>>> >>>>> qbv_count field will be removed in a future patch. >>>>> >>>>> Test ran: >>>>> >>>>> 1. Verify reset adapter behaviour in i225/6: >>>>> a) Enrol a new GCL >>>>> Reset adapter observed (tx mode change legacy->tsn) >>>>> b) Enrol a new GCL without deleting qdisc >>>>> No reset adapter observed (tx mode remain tsn->tsn) >>>>> c) Delete qdisc >>>>> Reset adapter observed (tx mode change tsn->legacy) >>>>> >>>>> 2. Tested scenario from "igc: Fix TX Hang issue when QBV Gate is closed" >>>>> to confirm it remains resolved. >>>>> >>>>> Fixes: 175c241288c0 ("igc: Fix TX Hang issue when QBV Gate is closed") >>>>> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com> >>>>> Reviewed-by: Simon Horman <horms@kernel.org> >>>>> --- >>>> >>>> There were a quite a few bugs, some of them my fault, on this part of >>>> the code, changing between the modes in the hardware. >>>> >>>> So I would like some confirmation that ETF offloading/LaunchTime was >>>> also tested with this change. Just to be sure. >>>> >>>> But code-wise, looks good: >>>> >>>> Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> >>>> >>>> >>>> Cheers, >>> >>> >>> Tested etf with offload, looks like working correctly. >>> >>> 1. mqprio >>> tc qdisc add dev enp1s0 handle 100: parent root mqprio num_tc 3 \ >>> map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \ >>> queues 1@0 1@1 2@2 \ >>> hw 0 >>> >>> No reset adapter observed. >>> >>> 2. etf with offload >>> tc qdisc replace dev enp1s0 parent 100:1 etf \ >>> clockid CLOCK_TAI delta 300000 offload >>> >>> Reset adapter observed (tx mode legacy -> tsn). >>> >>> 3. delete qdisc >>> tc qdisc delete dev enp1s0 parent root handle 100 >>> >>> Reset adapter observed (tx mode tsn -> legacy). >>> >> >> That no unexpected resets are happening, is good. >> >> But what I had in mind was some functional tests that ETF is working. I >> guess that's the only way of knowing that it's still working. Sorry that >> I wasn't clear about that. >> >> >> Cheers, > > My bad. > > Just tested ETF functionality and it is working. > Awesome. Thanks for the confirmation: Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Cheers,
Vinicius Costa Gomes <vinicius.gomes@intel.com> writes: > From: Vinicius Costa Gomes <vinicius.gomes@intel.com> > Hi, > > "Abdul Rahim, Faizal" <faizal.abdul.rahim@linux.intel.com> writes: > > > On 12/7/2024 1:10 am, Vinicius Costa Gomes wrote: > >> "Abdul Rahim, Faizal" <faizal.abdul.rahim@linux.intel.com> writes: > >> > >>> Hi Vinicius, > >>> > >>> On 11/7/2024 6:44 am, Vinicius Costa Gomes wrote: > >>>> Faizal Rahim <faizal.abdul.rahim@linux.intel.com> writes: > >>>> > >>>>> Following the "igc: Fix TX Hang issue when QBV Gate is close" changes, > >>>>> remaining issues with the reset adapter logic in igc_tsn_offload_apply() > >>>>> have been observed: > >>>>> > >>>>> 1. The reset adapter logics for i225 and i226 differ, although they should > >>>>> be the same according to the guidelines in I225/6 HW Design Section > >>>>> 7.5.2.1 on software initialization during tx mode changes. > >>>>> 2. The i225 resets adapter every time, even though tx mode doesn't > change. > >>>>> This occurs solely based on the condition igc_is_device_id_i225() when > >>>>> calling schedule_work(). > >>>>> 3. i226 doesn't reset adapter for tsn->legacy tx mode changes. It only > >>>>> resets adapter for legacy->tsn tx mode transitions. > >>>>> 4. qbv_count introduced in the patch is actually not needed; in this > >>>>> context, a non-zero value of qbv_count is used to indicate if tx mode > >>>>> was unconditionally set to tsn in igc_tsn_enable_offload(). This could > >>>>> be replaced by checking the existing register > >>>>> IGC_TQAVCTRL_TRANSMIT_MODE_TSN bit. > >>>>> > >>>>> This patch resolves all issues and enters schedule_work() to reset the > >>>>> adapter only when changing tx mode. It also removes reliance on > qbv_count. > >>>>> > >>>>> qbv_count field will be removed in a future patch. > >>>>> > >>>>> Test ran: > >>>>> > >>>>> 1. Verify reset adapter behaviour in i225/6: > >>>>> a) Enrol a new GCL > >>>>> Reset adapter observed (tx mode change legacy->tsn) > >>>>> b) Enrol a new GCL without deleting qdisc > >>>>> No reset adapter observed (tx mode remain tsn->tsn) > >>>>> c) Delete qdisc > >>>>> Reset adapter observed (tx mode change tsn->legacy) > >>>>> > >>>>> 2. Tested scenario from "igc: Fix TX Hang issue when QBV Gate is closed" > >>>>> to confirm it remains resolved. > >>>>> > >>>>> Fixes: 175c241288c0 ("igc: Fix TX Hang issue when QBV Gate is closed") > >>>>> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com> > >>>>> Reviewed-by: Simon Horman <horms@kernel.org> > >>>>> --- > >>>> > >>>> There were a quite a few bugs, some of them my fault, on this part of > >>>> the code, changing between the modes in the hardware. > >>>> > >>>> So I would like some confirmation that ETF offloading/LaunchTime was > >>>> also tested with this change. Just to be sure. > >>>> > >>>> But code-wise, looks good: > >>>> > >>>> Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> > >>>> > >>>> > >>>> Cheers, > >>> > >>> > >>> Tested etf with offload, looks like working correctly. > >>> > >>> 1. mqprio > >>> tc qdisc add dev enp1s0 handle 100: parent root mqprio num_tc 3 \ > >>> map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \ > >>> queues 1@0 1@1 2@2 \ > >>> hw 0 > >>> > >>> No reset adapter observed. > >>> > >>> 2. etf with offload > >>> tc qdisc replace dev enp1s0 parent 100:1 etf \ > >>> clockid CLOCK_TAI delta 300000 offload > >>> > >>> Reset adapter observed (tx mode legacy -> tsn). > >>> > >>> 3. delete qdisc > >>> tc qdisc delete dev enp1s0 parent root handle 100 > >>> > >>> Reset adapter observed (tx mode tsn -> legacy). > >>> > >> > >> That no unexpected resets are happening, is good. > >> > >> But what I had in mind was some functional tests that ETF is working. I > >> guess that's the only way of knowing that it's still working. Sorry that > >> I wasn't clear about that. > >> > >> > >> Cheers, > > > > My bad. > > > > Just tested ETF functionality and it is working. > > > > Awesome. Thanks for the confirmation: > > Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> > > > Cheers, > -- > Vinicius Hello Vinicius and Abdul, (I wanted to reply to the original email from Abdul, but I subscribed too late, so I'm replying to the last message. Apologies in advance) This patch is very useful for us in L-Acoustics. According to Milan/AVB specification, we must use CBS for streaming audio. Until this patch, we could not change the CBS configuration at runtime for i225. For instance, adding or removing streams would cause the card to reset and drop all streams. To be precise, we submit a netlink request via `tc change` command every time a stream is added/removed. We were using a home-made patch that I planned to submit, but I forgot.. I tested this patch, and it is working as expected for CBS runtime changes. Thank you!
On 07/07/2024 15:53, Faizal Rahim wrote: > Following the "igc: Fix TX Hang issue when QBV Gate is close" changes, > remaining issues with the reset adapter logic in igc_tsn_offload_apply() > have been observed: > > 1. The reset adapter logics for i225 and i226 differ, although they should > be the same according to the guidelines in I225/6 HW Design Section > 7.5.2.1 on software initialization during tx mode changes. > 2. The i225 resets adapter every time, even though tx mode doesn't change. > This occurs solely based on the condition igc_is_device_id_i225() when > calling schedule_work(). > 3. i226 doesn't reset adapter for tsn->legacy tx mode changes. It only > resets adapter for legacy->tsn tx mode transitions. > 4. qbv_count introduced in the patch is actually not needed; in this > context, a non-zero value of qbv_count is used to indicate if tx mode > was unconditionally set to tsn in igc_tsn_enable_offload(). This could > be replaced by checking the existing register > IGC_TQAVCTRL_TRANSMIT_MODE_TSN bit. > > This patch resolves all issues and enters schedule_work() to reset the > adapter only when changing tx mode. It also removes reliance on qbv_count. > > qbv_count field will be removed in a future patch. > > Test ran: > > 1. Verify reset adapter behaviour in i225/6: > a) Enrol a new GCL > Reset adapter observed (tx mode change legacy->tsn) > b) Enrol a new GCL without deleting qdisc > No reset adapter observed (tx mode remain tsn->tsn) > c) Delete qdisc > Reset adapter observed (tx mode change tsn->legacy) > > 2. Tested scenario from "igc: Fix TX Hang issue when QBV Gate is closed" > to confirm it remains resolved. > > Fixes: 175c241288c0 ("igc: Fix TX Hang issue when QBV Gate is closed") > 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> > Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> > --- > drivers/net/ethernet/intel/igc/igc_tsn.c | 23 ++++++++++++++++++++--- > 1 file changed, 20 insertions(+), 3 deletions(-) > Tested-by: Mor Bar-Gabay <morx.bar.gabay@intel.com>
diff --git a/drivers/net/ethernet/intel/igc/igc_tsn.c b/drivers/net/ethernet/intel/igc/igc_tsn.c index f6eaa288926e..9fafe275f30f 100644 --- a/drivers/net/ethernet/intel/igc/igc_tsn.c +++ b/drivers/net/ethernet/intel/igc/igc_tsn.c @@ -49,6 +49,13 @@ static unsigned int igc_tsn_new_flags(struct igc_adapter *adapter) return new_flags; } +static bool igc_tsn_is_tx_mode_in_tsn(struct igc_adapter *adapter) +{ + struct igc_hw *hw = &adapter->hw; + + return !!(rd32(IGC_TQAVCTRL) & IGC_TQAVCTRL_TRANSMIT_MODE_TSN); +} + void igc_tsn_adjust_txtime_offset(struct igc_adapter *adapter) { struct igc_hw *hw = &adapter->hw; @@ -331,15 +338,25 @@ int igc_tsn_reset(struct igc_adapter *adapter) return err; } +static bool igc_tsn_will_tx_mode_change(struct igc_adapter *adapter) +{ + bool any_tsn_enabled = (bool)(igc_tsn_new_flags(adapter) & + IGC_FLAG_TSN_ANY_ENABLED); + + return (any_tsn_enabled && !igc_tsn_is_tx_mode_in_tsn(adapter)) || + (!any_tsn_enabled && igc_tsn_is_tx_mode_in_tsn(adapter)); +} + int igc_tsn_offload_apply(struct igc_adapter *adapter) { struct igc_hw *hw = &adapter->hw; - /* Per I225/6 HW Design Section 7.5.2.1, transmit mode - * cannot be changed dynamically. Require reset the adapter. + /* Per I225/6 HW Design Section 7.5.2.1 guideline, if tx mode change + * from legacy->tsn or tsn->legacy, then reset adapter is needed. */ if (netif_running(adapter->netdev) && - (igc_is_device_id_i225(hw) || !adapter->qbv_count)) { + (igc_is_device_id_i225(hw) || igc_is_device_id_i226(hw)) && + igc_tsn_will_tx_mode_change(adapter)) { schedule_work(&adapter->reset_task); return 0; }
Following the "igc: Fix TX Hang issue when QBV Gate is close" changes, remaining issues with the reset adapter logic in igc_tsn_offload_apply() have been observed: 1. The reset adapter logics for i225 and i226 differ, although they should be the same according to the guidelines in I225/6 HW Design Section 7.5.2.1 on software initialization during tx mode changes. 2. The i225 resets adapter every time, even though tx mode doesn't change. This occurs solely based on the condition igc_is_device_id_i225() when calling schedule_work(). 3. i226 doesn't reset adapter for tsn->legacy tx mode changes. It only resets adapter for legacy->tsn tx mode transitions. 4. qbv_count introduced in the patch is actually not needed; in this context, a non-zero value of qbv_count is used to indicate if tx mode was unconditionally set to tsn in igc_tsn_enable_offload(). This could be replaced by checking the existing register IGC_TQAVCTRL_TRANSMIT_MODE_TSN bit. This patch resolves all issues and enters schedule_work() to reset the adapter only when changing tx mode. It also removes reliance on qbv_count. qbv_count field will be removed in a future patch. Test ran: 1. Verify reset adapter behaviour in i225/6: a) Enrol a new GCL Reset adapter observed (tx mode change legacy->tsn) b) Enrol a new GCL without deleting qdisc No reset adapter observed (tx mode remain tsn->tsn) c) Delete qdisc Reset adapter observed (tx mode change tsn->legacy) 2. Tested scenario from "igc: Fix TX Hang issue when QBV Gate is closed" to confirm it remains resolved. Fixes: 175c241288c0 ("igc: Fix TX Hang issue when QBV Gate is closed") Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com> Reviewed-by: Simon Horman <horms@kernel.org> --- drivers/net/ethernet/intel/igc/igc_tsn.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-)