From: Jeremy Kerr
Date: Wed, 17 Jun 2020 08:56:39 +0800
> [If you have any hints for forcing clustered packets, I'll see if I can
> probe the behaviour a little better to confirm]
Probably it would involve having packets arrive back to back faster
than some interval that either depends upon real
From: Jeremy Kerr
Date: Mon, 15 Jun 2020 10:54:56 +0800
> Using a AX88179 device (0b95:1790), I see two bytes of appended data on
> every RX packet. For example, this 48-byte ping, using 0xff as a
> payload byte:
>
> 04:20:22.528472 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 2447,
>
From: Jeremy Kerr
> Sent: 15 June 2020 03:55
While you are looking as this driver you might want to worry
about what it sets skp->truesize to.
> --- a/drivers/net/usb/ax88179_178a.c
> +++ b/drivers/net/usb/ax88179_178a.c
> @@ -1414,10 +1414,10 @@ static int ax88179_rx_fixup(struct usbnet *dev,
>
Hi David,
> It seems logical to me that what the chip does is align up the total
> sub-packet length to a multiple of 4 or larger, and then add those two
> prefix padding bytes. Otherwise the prefix padding won't necessarily
> and reliably align the IP header after the link level header.
Yep, th
From: Jeremy Kerr
Date: Tue, 16 Jun 2020 17:08:23 +0800
>> Because that code in this loop makes the same calculations:
>>
>> ax_skb = skb_clone(skb, GFP_ATOMIC);
>> if (ax_skb) {
>> ax_skb->len = pkt_len;
>> ax_skb->
Hi David,
> > Those last two bytes - 96 1f - aren't part of the original packet.
>
> Does this happen for non-tail packets in a multi-packet cluster?
I believe so, yes. I haven't been able to reliably reproduce the multi-
packet behaviour though, so input from ASIX would be good.
>
> Because t
...@ozlabs.org
Cc: netdev@vger.kernel.org; al...@asix.com.tw; fre...@asix.com.tw;
pf...@christ-es.de; linux-...@vger.kernel.org
Subject: Re: [PATCH] net: usb: ax88179_178a: fix packet alignment padding
From: Jeremy Kerr
Date: Mon, 15 Jun 2020 10:54:56 +0800
> Using a AX88179 device (0b95:1790), I
From: Jeremy Kerr
Date: Mon, 15 Jun 2020 10:54:56 +0800
> Using a AX88179 device (0b95:1790), I see two bytes of appended data on
> every RX packet. For example, this 48-byte ping, using 0xff as a
> payload byte:
>
> 04:20:22.528472 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 2447,
>
Using a AX88179 device (0b95:1790), I see two bytes of appended data on
every RX packet. For example, this 48-byte ping, using 0xff as a
payload byte:
04:20:22.528472 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 2447, seq
1, length 64
0x: 000a cd35 ea50 000a cd35 ea4f 0800 4
Hi Louis,
> Thanks for the correction.
> Indeed, the hardware adds two bytes dummy data at beginning of
> Ethernet packet to make IP header aligned.
> The original patch made by Freddy contains the length of dummy
> header.
OK, thanks for checking. I understand this to mean that the fix is
corr
: Peter Fink ; netdev@vger.kernel.org;
linux-...@vger.kernel.org
Subject: Re: [RFC PATCH] net: usb: ax88179_178a: fix packet alignment padding
Hi Freddy and Allan,
Just following up on the RFC patch below: Can you confirm whether the packet
len (in the hardware-provided packet RX metadata) includes
, 2020 11:18 AM
To: Freddy Xin ; Allan Chou
Cc: Peter Fink ; netdev@vger.kernel.org;
linux-...@vger.kernel.org
Subject: Re: [RFC PATCH] net: usb: ax88179_178a: fix packet alignment padding
Hi Freddy and Allan,
Just following up on the RFC patch below: Can you confirm whether the packet
len (in
Hi Freddy and Allan,
Just following up on the RFC patch below: Can you confirm whether the
packet len (in the hardware-provided packet RX metadata) includes the
two-byte padding field? Is this the same for all ax88179 devices?
Cheers,
Jeremy
> Using a AX88179 device (0b95:1790), I see two byte
Using a AX88179 device (0b95:1790), I see two bytes of appended data on
every RX packet. For example, this 48-byte ping, using 0xff as a
payload byte:
04:20:22.528472 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 2447, seq
1, length 64
0x: 000a cd35 ea50 000a cd35 ea4f 0800 4
14 matches
Mail list logo
