Messages in this thread | | | From | Linus Walleij <> | Date | Mon, 30 Oct 2023 15:32:10 +0100 | Subject | Re: [PATCH] dsa: tag_rtl4_a: Bump min packet size |
| |
Hi Deng,
do you have some comments on the below, pertaining to commit 9eb8bc593a5eed167dac2029abef343854c5ba75 "net: dsa: tag_rtl4_a: fix egress tags"?
I plan to test without the ZLEN padding and see what happens. IIRC it wasn't working without that, but I may just misremember the whole thing so let's rehash this.
On Mon, Oct 30, 2023 at 1:51 PM Vladimir Oltean <olteanv@gmail.com> wrote:
> What you are missing is that the existing padding done by rtl4a_tag_xmit() > shouldn't be normally needed except for exceptional cases. > > Socket buffers smaller than ETH_ZLEN can be passed to any network > device, and it is expected that either the driver or the hardware pads > up to ETH_ZLEN automatically. Thus, the conduit driver should already > know that it needs to pad packets to ETH_ZLEN. > > The exceptional cases are: > - This is a tail tag (not the case here), which by definition needs to > be located at the end of the skb. If you first put the tag then let > the conduit interface pad, then the tail tag is no longer at the tail. > So in that case, DSA pads first in generic code - dsa_user_xmit(). > - The switch must handle the case where, after stripping the DSA tag > from a ETH_ZLEN sized packet coming from the CPU port, it re-pads the > packet on user port egress. Some switches don't handle that properly, > and thus, we have isolated __skb_put_padto() calls within certain > tagging protocols which address just that case. > > So, what Florian was asking is whether the conduit interface is not > doing its expected job properly. You clarified that the problem is big > rather than small packets, but we still need an explanation for the > existing __skb_put_padto() call, given that it seems that it was placed > there due to a misunderstanding rather than due to an explicit need for > an exceptional case.
Yours, Linus Walleij
| |