* [Intel-wired-lan] [PATCH net v2] e1000e: Disable TSO on i219-LM card to increase speed
@ 2022-12-21 13:25 Mateusz Palczewski
2022-12-21 15:24 ` Paul Menzel
2023-01-11 20:34 ` Tony Nguyen
0 siblings, 2 replies; 7+ messages in thread
From: Mateusz Palczewski @ 2022-12-21 13:25 UTC (permalink / raw)
To: intel-wired-lan
While using i219-LM card currently it was only possible to achieve
about 60% of maximum speed due to regression introduced in Linux 5.8-rc1.
This was caused by TSO not being disabled by default despite commit
f29801030ac6 implementation. Fix that by moving the part of the code
responsible for this outside of adapter->flags & FLAG_TSO_FORCE check.
Fixes: f29801030ac6 ("e1000e: Disable TSO for buffer overrun workaround")
Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
---
v2: Fixed commit message and comment inside the code
---
drivers/net/ethernet/intel/e1000e/netdev.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 04acd1a992fa..2f5cf125ff77 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5307,10 +5307,6 @@ static void e1000_watchdog_task(struct work_struct *work)
/* oops */
break;
}
- if (hw->mac.type == e1000_pch_spt) {
- netdev->features &= ~NETIF_F_TSO;
- netdev->features &= ~NETIF_F_TSO6;
- }
}
/* enable transmits in the hardware, need to do this
@@ -5326,6 +5322,14 @@ static void e1000_watchdog_task(struct work_struct *work)
if (phy->ops.cfg_on_link_up)
phy->ops.cfg_on_link_up(hw);
+ /* Disable TSO for i219 to avoid transfer speed
+ * being capped at 60%.
+ */
+ if (hw->mac.type == e1000_pch_spt) {
+ netdev->features &= ~NETIF_F_TSO;
+ netdev->features &= ~NETIF_F_TSO6;
+ }
+
netif_wake_queue(netdev);
netif_carrier_on(netdev);
--
2.31.1
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [Intel-wired-lan] [PATCH net v2] e1000e: Disable TSO on i219-LM card to increase speed
2022-12-21 13:25 [Intel-wired-lan] [PATCH net v2] e1000e: Disable TSO on i219-LM card to increase speed Mateusz Palczewski
@ 2022-12-21 15:24 ` Paul Menzel
2022-12-28 10:43 ` Palczewski, Mateusz
2023-01-11 20:34 ` Tony Nguyen
1 sibling, 1 reply; 7+ messages in thread
From: Paul Menzel @ 2022-12-21 15:24 UTC (permalink / raw)
To: Mateusz Palczewski
Cc: Jesse Brandeburg, Kai-Heng Feng, Tony Nguyen, Jakub Kicinski,
intel-wired-lan
Dear Mateusz,
Thank you for the second iteration.
Am 21.12.22 um 14:25 schrieb Mateusz Palczewski:
> While using i219-LM card currently it was only possible to achieve
> about 60% of maximum speed due to regression introduced in Linux 5.8-rc1.
> This was caused by TSO not being disabled by default despite commit
> f29801030ac6 implementation. Fix that by moving the part of the code
> responsible for this outside of adapter->flags & FLAG_TSO_FORCE check.
Unfortunately, you missed to add all the information, that this can’t be
reproduced in all situations, and you also forgot to add the datasheet
section, where it’s written that TSO needs to be disabled.
> Fixes: f29801030ac6 ("e1000e: Disable TSO for buffer overrun workaround")
Why does
if (!(adapter->flags & FLAG_TSO_FORCE)) {
[…]
if (hw->mac.type == e1000_pch_spt) {
not work in your situation? Is `FLAG_TSO_FORCE` set for network namespaces?
Anyway, I’d say, it’s the wrong commit to reference, as it does not
introduce the performance regression you are seeing.
And now having dug in more into this change, I do not think, it can be
accepted as is, as disabling TCP Segmentation Offload (TSO) would be a
potential performance regression (CPU usage) on a lot of systems.
> Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
> ---
> v2: Fixed commit message and comment inside the code
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
> index 04acd1a992fa..2f5cf125ff77 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -5307,10 +5307,6 @@ static void e1000_watchdog_task(struct work_struct *work)
> /* oops */
> break;
> }
> - if (hw->mac.type == e1000_pch_spt) {
> - netdev->features &= ~NETIF_F_TSO;
> - netdev->features &= ~NETIF_F_TSO6;
> - }
> }
>
> /* enable transmits in the hardware, need to do this
> @@ -5326,6 +5322,14 @@ static void e1000_watchdog_task(struct work_struct *work)
> if (phy->ops.cfg_on_link_up)
> phy->ops.cfg_on_link_up(hw);
>
> + /* Disable TSO for i219 to avoid transfer speed
> + * being capped at 60%.
> + */
The results of the analysis would need to be added here, and the comment
extended.
> + if (hw->mac.type == e1000_pch_spt) {
> + netdev->features &= ~NETIF_F_TSO;
> + netdev->features &= ~NETIF_F_TSO6;
> + }
> +
> netif_wake_queue(netdev);
> netif_carrier_on(netdev);
>
Kind regards,
Paul
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Intel-wired-lan] [PATCH net v2] e1000e: Disable TSO on i219-LM card to increase speed
2022-12-21 15:24 ` Paul Menzel
@ 2022-12-28 10:43 ` Palczewski, Mateusz
2023-01-03 12:25 ` Paul Menzel
0 siblings, 1 reply; 7+ messages in thread
From: Palczewski, Mateusz @ 2022-12-28 10:43 UTC (permalink / raw)
To: Paul Menzel
Cc: Brandeburg, Jesse, Kai-Heng Feng, Nguyen, Anthony L,
Jakub Kicinski, intel-wired-lan
Hi,
sorry for late respond but I needed to create new setup to be sure that this issue is not related to namespaces.
>Dear Mateusz,
>
>
>Thank you for the second iteration.
>
>Am 21.12.22 um 14:25 schrieb Mateusz Palczewski:
>> While using i219-LM card currently it was only possible to achieve
>> about 60% of maximum speed due to regression introduced in Linux 5.8-rc1.
>> This was caused by TSO not being disabled by default despite commit
>> f29801030ac6 implementation. Fix that by moving the part of the code
>> responsible for this outside of adapter->flags & FLAG_TSO_FORCE check.
>
>Unfortunately, you missed to add all the information, that this can’t be reproduced in all situations, and you also forgot to add the datasheet section, where it’s written that TSO needs to be disabled.
>
>> Fixes: f29801030ac6 ("e1000e: Disable TSO for buffer overrun
>> workaround")
>
>Why does
>
> if (!(adapter->flags & FLAG_TSO_FORCE)) {
> […]
> if (hw->mac.type == e1000_pch_spt) {
>
>not work in your situation? Is `FLAG_TSO_FORCE` set for network namespaces?
>
I have tested this on new setup and without this patch I still see the speed being aroung only ~690 Mbits/sec and after applying it stable 934 Mbits/sec
To give more information on the setup - I have tested it with i219-LM that is built into server with Intel Skylake chip. The results are the same for connection using namespaces in the same server as well as having it connected to another server.
>Anyway, I’d say, it’s the wrong commit to reference, as it does not introduce the performance regression you are seeing.
>
>And now having dug in more into this change, I do not think, it can be accepted as is, as disabling TCP Segmentation Offload (TSO) would be a potential performance regression (CPU usage) on a lot of systems.
>
Can You please elaborate more on that?
>> Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
>> ---
>> v2: Fixed commit message and comment inside the code
>> ---
>> drivers/net/ethernet/intel/e1000e/netdev.c | 12 ++++++++----
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
>> b/drivers/net/ethernet/intel/e1000e/netdev.c
>> index 04acd1a992fa..2f5cf125ff77 100644
>> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
>> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
>> @@ -5307,10 +5307,6 @@ static void e1000_watchdog_task(struct work_struct *work)
>> /* oops */
>> break;
>> }
>> - if (hw->mac.type == e1000_pch_spt) {
>> - netdev->features &= ~NETIF_F_TSO;
>> - netdev->features &= ~NETIF_F_TSO6;
>> - }
>> }
>>
>> /* enable transmits in the hardware, need to do this @@ -5326,6
>> +5322,14 @@ static void e1000_watchdog_task(struct work_struct *work)
>> if (phy->ops.cfg_on_link_up)
>> phy->ops.cfg_on_link_up(hw);
>>
>> + /* Disable TSO for i219 to avoid transfer speed
>> + * being capped at 60%.
>> + */
>
>The results of the analysis would need to be added here, and the comment extended.
>
>> + if (hw->mac.type == e1000_pch_spt) {
>> + netdev->features &= ~NETIF_F_TSO;
>> + netdev->features &= ~NETIF_F_TSO6;
>> + }
>> +
>> netif_wake_queue(netdev);
>> netif_carrier_on(netdev);
>>
>
>
>Kind regards,
>
>Paul
>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Intel-wired-lan] [PATCH net v2] e1000e: Disable TSO on i219-LM card to increase speed
2022-12-28 10:43 ` Palczewski, Mateusz
@ 2023-01-03 12:25 ` Paul Menzel
2023-01-03 15:15 ` Palczewski, Mateusz
0 siblings, 1 reply; 7+ messages in thread
From: Paul Menzel @ 2023-01-03 12:25 UTC (permalink / raw)
To: Mateusz Palczewski
Cc: Jesse Brandeburg, Kai-Heng Feng, Anthony L Nguyen,
Jakub Kicinski, intel-wired-lan
Dear Mateusz,
Am 28.12.22 um 11:43 schrieb Palczewski, Mateusz:
> sorry for late respond but I needed to create new setup to be sure
> that this issue is not related to namespaces.
No problem. Thank you for your reply, and sorry for my late response due
to the holidays.
>> Am 21.12.22 um 14:25 schrieb Mateusz Palczewski:
>>> While using i219-LM card currently it was only possible to achieve
>>> about 60% of maximum speed due to regression introduced in Linux 5.8-rc1.
>>> This was caused by TSO not being disabled by default despite commit
>>> f29801030ac6 implementation. Fix that by moving the part of the code
>>> responsible for this outside of adapter->flags & FLAG_TSO_FORCE check.
>>
>> Unfortunately, you missed to add all the information, that this
>> can’t be reproduced in all situations, and you also forgot to add
>> the datasheet section, where it’s written that TSO needs to be
>> disabled.
>>
>>> Fixes: f29801030ac6 ("e1000e: Disable TSO for buffer overrun
>>> workaround")
>>
>> Why does
>>
>> if (!(adapter->flags & FLAG_TSO_FORCE)) {
>> […]
>> if (hw->mac.type == e1000_pch_spt) {
>>
>> not work in your situation? Is `FLAG_TSO_FORCE` set for network namespaces?
> > I have tested this on new setup and without this patch I still see
> the speed being aroung only ~690 Mbits/sec and after applying it
> stable 934 Mbits/sec
Please provide the instructions how to set up the network namespace,
that I can test that.
> To give more information on the setup - I have tested it with i219-LM
> that is built into server with Intel Skylake chip. The results are
> the same for connection using namespaces in the same server as well
> as having it connected to another server.
I only tested this on desktops. Please give more details on the actual
device (`lspci -nn`).
Please figure out, with a debugger, tracing or print statements, why the
condition above is not reached in your setup.
>> Anyway, I’d say, it’s the wrong commit to reference, as it does
>> not introduce the performance regression you are seeing. >>
>> And now having dug in more into this change, I do not think, it can
>> be accepted as is, as disabling TCP Segmentation Offload (TSO)
>> would be a potential performance regression (CPU usage) on a lot of
>> systems.
>>
> Can You please elaborate more on that?
If you disable TSO the “calculations“ are done on the CPU instead of the
network device, so less compute resources are available for computing.
As it works fine on the systems I tested with, it would be a performance
regression, on the systems, where your problem does not occur.
Kind regards,
Paul
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Intel-wired-lan] [PATCH net v2] e1000e: Disable TSO on i219-LM card to increase speed
2023-01-03 12:25 ` Paul Menzel
@ 2023-01-03 15:15 ` Palczewski, Mateusz
2023-01-03 18:04 ` Paul Menzel
0 siblings, 1 reply; 7+ messages in thread
From: Palczewski, Mateusz @ 2023-01-03 15:15 UTC (permalink / raw)
To: Paul Menzel
Cc: Brandeburg, Jesse, Kai-Heng Feng, Nguyen, Anthony L,
Jakub Kicinski, intel-wired-lan
Hello
>
>Dear Mateusz,
>
>
>Am 28.12.22 um 11:43 schrieb Palczewski, Mateusz:
>
>> sorry for late respond but I needed to create new setup to be sure
>> that this issue is not related to namespaces.
>
>No problem. Thank you for your reply, and sorry for my late response due to the holidays.
>
>>> Am 21.12.22 um 14:25 schrieb Mateusz Palczewski:
>>>> While using i219-LM card currently it was only possible to achieve
>>>> about 60% of maximum speed due to regression introduced in Linux 5.8-rc1.
>>>> This was caused by TSO not being disabled by default despite commit
>>>> f29801030ac6 implementation. Fix that by moving the part of the code
>>>> responsible for this outside of adapter->flags & FLAG_TSO_FORCE check.
>>>
>>> Unfortunately, you missed to add all the information, that this can’t
>>> be reproduced in all situations, and you also forgot to add the
>>> datasheet section, where it’s written that TSO needs to be disabled.
>>>
>>>> Fixes: f29801030ac6 ("e1000e: Disable TSO for buffer overrun
>>>> workaround")
>>>
>>> Why does
>>>
>>> if (!(adapter->flags & FLAG_TSO_FORCE)) {
>>> […]
>>> if (hw->mac.type == e1000_pch_spt) {
>>>
>>> not work in your situation? Is `FLAG_TSO_FORCE` set for network namespaces?
>> > I have tested this on new setup and without this patch I still see
>> the speed being aroung only ~690 Mbits/sec and after applying it
>> stable 934 Mbits/sec
>
>Please provide the instructions how to set up the network namespace, that I can test that.
In my setup i219 interface is called eno1 and it's connected Back2Back with other card inside same server ens1f3.
I have created new namespace using "ip netns add test", then I have added my i219 interface using " ip link set eno1 netns test",
bring it up using "ip netns exec test ifconfig eno1 up", added ip addresses to both of the interfaces
"ip netns exec test ip addr add 10.1.1.1/24 dev eno1" on namespace interface and "ip addr add 10.1.1.2/24 dev ens1f3".
Then on one terminal I ran "ip netns exec test iperf3 -c 10.1.1.2" and on the second one "iperf3 -s". This resulted on the speed being capped
at ~690Mbits/s.
But after Your comments I have changed my setup to have i219 connected to another server to avoid using namespaces. The results are that the TSO seems to be disabled by default right after the system boots with e1000e driver, but after reloading it with rmmod and modprobe it seems to be disabled by default. I will dig more into it. But please tell me if You observe the same thing.
>
>> To give more information on the setup - I have tested it with i219-LM
>> that is built into server with Intel Skylake chip. The results are the
>> same for connection using namespaces in the same server as well as
>> having it connected to another server.
>
>I only tested this on desktops. Please give more details on the actual device (`lspci -nn`).
Here is my output
# lspci -nn | grep "Eth"
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (3) I219-LM [8086:15b9] (rev 09)
>
>Please figure out, with a debugger, tracing or print statements, why the condition above is not reached in your setup.
I will try to test more if maybe this issue is present only after reloading the driver instead of namespaces themselves.
>
>>> Anyway, I’d say, it’s the wrong commit to reference, as it does not
>>> introduce the performance regression you are seeing. >> And now
>>> having dug in more into this change, I do not think, it can be
>>> accepted as is, as disabling TCP Segmentation Offload (TSO) would be
>>> a potential performance regression (CPU usage) on a lot of systems.
>>>
>> Can You please elaborate more on that?
>
>If you disable TSO the “calculations“ are done on the CPU instead of the network device, so less compute resources are available for computing.
>As it works fine on the systems I tested with, it would be a performance regression, on the systems, where your problem does not occur.
>
>
>Kind regards,
>
>Paul
>
Regards,
Mateusz
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Intel-wired-lan] [PATCH net v2] e1000e: Disable TSO on i219-LM card to increase speed
2023-01-03 15:15 ` Palczewski, Mateusz
@ 2023-01-03 18:04 ` Paul Menzel
0 siblings, 0 replies; 7+ messages in thread
From: Paul Menzel @ 2023-01-03 18:04 UTC (permalink / raw)
To: Mateusz Palczewski
Cc: Jakub Kicinski, Kai-Heng Feng, Anthony L Nguyen,
Jesse Brandeburg, intel-wired-lan
Dear Mateusz,
Am 03.01.23 um 16:15 schrieb Palczewski, Mateusz:
>> Am 28.12.22 um 11:43 schrieb Palczewski, Mateusz:
>>>> Am 21.12.22 um 14:25 schrieb Mateusz Palczewski:
>>>>> While using i219-LM card currently it was only possible to achieve
>>>>> about 60% of maximum speed due to regression introduced in Linux 5.8-rc1.
>>>>> This was caused by TSO not being disabled by default despite commit
>>>>> f29801030ac6 implementation. Fix that by moving the part of the code
>>>>> responsible for this outside of adapter->flags & FLAG_TSO_FORCE check.
>>>>
>>>> Unfortunately, you missed to add all the information, that this can’t
>>>> be reproduced in all situations, and you also forgot to add the
>>>> datasheet section, where it’s written that TSO needs to be disabled.
>>>>
>>>>> Fixes: f29801030ac6 ("e1000e: Disable TSO for buffer overrun
>>>>> workaround")
>>>>
>>>> Why does
>>>>
>>>> if (!(adapter->flags & FLAG_TSO_FORCE)) {
>>>> […]
>>>> if (hw->mac.type == e1000_pch_spt) {
>>>>
>>>> not work in your situation? Is `FLAG_TSO_FORCE` set for network namespaces?
>>> > I have tested this on new setup and without this patch I still see
>>> the speed being aroung only ~690 Mbits/sec and after applying it
>>> stable 934 Mbits/sec
>>
>> Please provide the instructions how to set up the network namespace, that I can test that.
>
> In my setup i219 interface is called eno1 and it's connected
> Back2Back with other card inside same server ens1f3. I have created
> new namespace using "ip netns add test", then I have added my i219
> interface using " ip link set eno1 netns test", bring it up using
> "ip netns exec test ifconfig eno1 up", added ip addresses to both of
> the interfaces "ip netns exec test ip addr add 10.1.1.1/24 dev eno1"
> on namespace interface and "ip addr add 10.1.1.2/24 dev ens1f3". Then
> on one terminal I ran "ip netns exec test iperf3 -c 10.1.1.2" and on
> the second one "iperf3 -s". This resulted on the speed being capped
> at ~690Mbits/s.
Thank you. (Though, I do not fully understand why you need a network
namespace to send traffic between two cards even in the same system.)
> But after Your comments I have changed my setup to have i219
> connected to another server to avoid using namespaces. The results
> are that the TSO seems to be disabled by default right after the
> system boots with e1000e driver, but after reloading it with rmmod
> and modprobe it seems to be disabled by default. I will dig more into
> it. But please tell me if You observe the same thing.
Very interesting. Discussing more about the issue, I now see that the
commit message summary confused me, and I assumed, TSO was enabled.
After the discussion, I checked with ethtool to find out, that it’s off
on the systems I tested with.
$ ethtool -k net00 | grep tcp-segmentation-offload
tcp-segmentation-offload: off
Turning it on with `sudo ethtool -K net00 tso on` indeed decreased the
bandwidth from 846 Mbits/sec to 507 Mbits/sec between two Dell Precision
3620 connected over an office switch.
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet
Connection (2) I219-LM [8086:15b7] (rev 31)
Removing and loading the module *e1000e* does not turn TSO on though here.
>>> To give more information on the setup - I have tested it with i219-LM
>>> that is built into server with Intel Skylake chip. The results are the
>>> same for connection using namespaces in the same server as well as
>>> having it connected to another server.
>>
>> I only tested this on desktops. Please give more details on the actual device (`lspci -nn`).
> Here is my output
>
> # lspci -nn | grep "Eth"
> 00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (3) I219-LM [8086:15b9] (rev 09)
(I would have hoped Intel to have fixed the TSO issue in newer
revisions. Do you know if that problem is known to the hardware guys.)
>> Please figure out, with a debugger, tracing or print statements,
>> why the condition above is not reached in your setup.
>
> I will try to test more if maybe this issue is present only after
> reloading the driver instead of namespaces themselves.
Good luck figuring it out.
>>>> Anyway, I’d say, it’s the wrong commit to reference, as it does not
>>>> introduce the performance regression you are seeing. >> And now
>>>> having dug in more into this change, I do not think, it can be
>>>> accepted as is, as disabling TCP Segmentation Offload (TSO) would be
>>>> a potential performance regression (CPU usage) on a lot of systems.
>>>>
>>> Can You please elaborate more on that?
>>
>> If you disable TSO the “calculations“ are done on the CPU instead
>> of the network device, so less compute resources are available for
>> computing. As it works fine on the systems I tested with, it would be
>> a performance regression, on the systems, where your problem does not
>> occur.
As TSO is off on my systems, my point is mood.
Kind regards,
Paul
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Intel-wired-lan] [PATCH net v2] e1000e: Disable TSO on i219-LM card to increase speed
2022-12-21 13:25 [Intel-wired-lan] [PATCH net v2] e1000e: Disable TSO on i219-LM card to increase speed Mateusz Palczewski
2022-12-21 15:24 ` Paul Menzel
@ 2023-01-11 20:34 ` Tony Nguyen
1 sibling, 0 replies; 7+ messages in thread
From: Tony Nguyen @ 2023-01-11 20:34 UTC (permalink / raw)
To: Mateusz Palczewski, intel-wired-lan
On 12/21/2022 5:25 AM, Mateusz Palczewski wrote:
> While using i219-LM card currently it was only possible to achieve
> about 60% of maximum speed due to regression introduced in Linux 5.8-rc1.
> This was caused by TSO not being disabled by default despite commit
> f29801030ac6 implementation. Fix that by moving the part of the code
> responsible for this outside of adapter->flags & FLAG_TSO_FORCE check.
Have you looked into changing the initial netdev features to prevent
this? Seems like it would be more effective to have it off fixed for
this MAC over turning it off in the watchdog every time.
>
> Fixes: f29801030ac6 ("e1000e: Disable TSO for buffer overrun workaround")
> Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
> ---
> v2: Fixed commit message and comment inside the code
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
> index 04acd1a992fa..2f5cf125ff77 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -5307,10 +5307,6 @@ static void e1000_watchdog_task(struct work_struct *work)
> /* oops */
> break;
> }
> - if (hw->mac.type == e1000_pch_spt) {
> - netdev->features &= ~NETIF_F_TSO;
> - netdev->features &= ~NETIF_F_TSO6;
> - }
> }
>
> /* enable transmits in the hardware, need to do this
> @@ -5326,6 +5322,14 @@ static void e1000_watchdog_task(struct work_struct *work)
> if (phy->ops.cfg_on_link_up)
> phy->ops.cfg_on_link_up(hw);
>
> + /* Disable TSO for i219 to avoid transfer speed
> + * being capped at 60%.
> + */
> + if (hw->mac.type == e1000_pch_spt) {
> + netdev->features &= ~NETIF_F_TSO;
> + netdev->features &= ~NETIF_F_TSO6;
> + }
> +
> netif_wake_queue(netdev);
> netif_carrier_on(netdev);
>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-01-11 20:35 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-21 13:25 [Intel-wired-lan] [PATCH net v2] e1000e: Disable TSO on i219-LM card to increase speed Mateusz Palczewski
2022-12-21 15:24 ` Paul Menzel
2022-12-28 10:43 ` Palczewski, Mateusz
2023-01-03 12:25 ` Paul Menzel
2023-01-03 15:15 ` Palczewski, Mateusz
2023-01-03 18:04 ` Paul Menzel
2023-01-11 20:34 ` Tony Nguyen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).