>On Sun, Oct 16, 2022 at 07:36:25PM +0800, Chun-Chao Yen 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> >> --- >> drivers/net/usb/ax88179_178a.c | 62 ++++++++++++++-------------------- >> 1 file changed, 26 insertions(+), 36 deletions(-) > >Why is this a RESEND? Hi, sorry for the confusion. "RESEND" (by the way, the actual tag "RESENT" is used as "re-sent", with no intention to imply anger) simply means, the exact same patches are sent out again. Since I have not received any acknowledgements or feedback yet for the first 3 patches sent on Oct 7, and the guideline says sometimes mails could be lost and we might resubmit them after a minimum of one week; so for that reason I tagged the same mails with "RESENT" (a bad choice of tag in hindsight) and sent them out again (also switched to a different maintainer's address to mail to). > >Always put below the --- what is happening, what is different from the >first version you sent? Sure, I will put my "re-sent" message there for similar cases in future. > >And why is this not threaded with the 2/3 and 3/3 patches? All 3 patches tagged with "RESENT" were sent at the same time, so I guess the other two are probably lost. Sorry again for the confusion/mess I have made. > >thanks, > >greg k-h I think your reply shows that my first 3 patches (sent on Oct 7) have successfully reached the kernel team and entered your processing queue; therefore please ignore the later ones tagged with "RESENT" (sent on Oct 16), and inform me of anything I need to know for this review. Many thanks and apologies, Chao
