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? 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. thanks, greg k-h
