>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@xxxxxxxxxxx> >> --- >> 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
