From: Michal Pecio <michal.pecio@gmail.com>
To: Petko Manolov <petkan@nucleusys.com>
Cc: I Viswanath <viswanathiyyappan@gmail.com>,
kuba@kernel.org, edumazet@google.com, andrew+netdev@lunn.ch,
davem@davemloft.net, pabeni@redhat.com,
linux-usb@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, skhan@linuxfoundation.org,
linux-kernel-mentees@lists.linux.dev,
david.hunter.linux@gmail.com,
syzbot+78cae3f37c62ad092caa@syzkaller.appspotmail.com
Subject: Re: [PATCH net v3] net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast
Date: Wed, 24 Sep 2025 22:42:39 +0200 [thread overview]
Message-ID: <20250924224239.3ec0fcca.michal.pecio@gmail.com> (raw)
In-Reply-To: <20250924195055.15735499.michal.pecio@gmail.com>
On Wed, 24 Sep 2025 19:50:55 +0200, Michal Pecio wrote:
> Do you happen to remember what was the reason for padding all TX frames
> to at least 60 bytes?
>
> This was apparently added in version "v0.5.0 (2002/03/28)".
>
> I'm yet to test the exact effect of this hack (will the HW really send
> frames with trailing garbage?) and what happens if it's removed (maybe
> nothing bad? or was there a HW bug?), but this part caught my attention
> because I think nowadays some people could consider it "information
> leak" ;) And it looks like a waste of bandwidth at least.
Sorry, stupid question, such frames are illegal.
That being said, I see that other drivers pad them with zeros or
other fixed pattern ('skb_padto(skb, ETH_ZLEN)' seems to be common)
rather than just DMA beyond the specified length.
next prev parent reply other threads:[~2025-09-24 20:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-24 13:43 [PATCH net v3] net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast I Viswanath
2025-09-24 13:58 ` Petko Manolov
2025-09-24 17:50 ` Michal Pecio
2025-09-24 20:42 ` Michal Pecio [this message]
2025-09-24 23:18 ` Jakub Kicinski
2025-09-25 1:57 ` viswanath
2025-09-26 22:20 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250924224239.3ec0fcca.michal.pecio@gmail.com \
--to=michal.pecio@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=david.hunter.linux@gmail.com \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel-mentees@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petkan@nucleusys.com \
--cc=skhan@linuxfoundation.org \
--cc=syzbot+78cae3f37c62ad092caa@syzkaller.appspotmail.com \
--cc=viswanathiyyappan@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.