[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-usb
Subject:    Re: Re: [PATCH 1/3 RFC] net: usb: ax88179_178a: Enable FLAG_MULTI_PACKET to improve tx stability
From:       Yen Chun-Chao <nothingstopsme () hotmail ! com>
Date:       2023-02-28 12:36:09
Message-ID: SY4P282MB2823BA36EDABF6EE71E74BB6D1AC9 () SY4P282MB2823 ! AUSP282 ! PROD ! OUTLOOK ! COM
[Download RAW message or body]

>On Tue, Feb 28, 2023 at 09:44:43AM +0000, Yen ChunChao wrote:
>> Problem Description:
>> The current way of handling the boundary case in tx, i.e. adding one-byte
>> padding when the size of an outbound packet is a multiple of the maximum
>> frame size used for USB bulk transfer, does not work with the hardware.
>> This can be shown by running a loading test via iperf with this hardware as
>> the sender; one can then tune the iperf parameters on the sender side (e.g.
>> "-M 510" in my testing environment) so that sent packets frequently hit the
>> boundary condition, and observe a significant drop in the transmission
>> rate. In the worst case (often after a long run), the hardware can stop
>> functioning (can not send or receive packets anymore, albeit the
>> corresponding network interface is still reported present by ifconfig).
>> 
>> It is also believed that this problem is highly relevant to this bug [1].
>> 
>> Solution:
>> Enable FLAG_MULTI_PACKET and modify both ax88179_rx_fixup() and
>> ax88179_tx_fixup() accordingly.
>> 
>> Rationale:
>> When FLAG_MULTI_PACKET is enabled (and FLAG_SEND_ZLP is off, which is the
>> case for this driver), usbnet will skip padding, and trust that each
>> sk_buff returned from the mini-driver's tx_fixup function has been taken
>> care of to cater for the requirement of its target hardware. That
>> mechanism allows this mini-driver to send, even when the boundary condition
>> is detected, "untampered" packets (no padding, no extra flags, as if in the
>> normal case) that the hardware accepts, and therefore resolves this
>> problem.
>> 
>> Note that rather than being viewed as a workaround, enabling
>> FLAG_MULTI_PACKET is intended to better match the overall behaviour of the
>> hardware, as it also echos well the rx procedure conducting multiple-packet
>> extraction from a single sk_buff in ax88179_rx_fixup().
>> 
>> Verification:
>> Only tested with this device:
>> 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
>> 
>> References:
>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=212731
>> 
>> Signed-off-by: Chun-Chao Yen <nothingstopsme@hotmail.com>
>> ---
>> This is the same patch as https://rb.gy/199s5m sent in Oct. 2022.
>> I just would like to know the current state of this patch.
>> Has it been rejected or still under review?
>
>Patches marked with "RFC" are never to be applied, what needs to be done
>on this in order for you to feel comfortable enough to submit it for
>actualy inclusion?

Sorry for the misuse of "RFC". I thought that tag could be used to ask 
questions about the patches sent previously when no change is added.

As you might have noticed in the message after "---", my intention is to 
check whether my patches are still under review or not, because I have 
not received any feedback/comments since they were sent out in Oct. 2022.

>
>Please do that and then send it out properly.
>
>Also, I think vger still bans hotmail.com emails, sorry, please use a
>better email provider if you wish to contribute to the kernel.

Thank you very much for this information. 

Since my patch mails have appeared at https://lore.kernel.org/linux-usb,  
should I treat all of them (sent from hotmail.com) as invalid, and
send the same patch series again using another email provider, 
in the way like I am sending them for the first time?

>
>thanks,
>
>greg k-h

Best,

Chao
[prev in list] [next in list] [prev in thread] [next in thread]