From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: Sending undersized ARP packets with VXLAN L3 interface Date: Wed, 27 Aug 2014 11:42:09 -0700 Message-ID: <20140827114209.3a9d3761@urahara> References: <53FE1AC3.5030409@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Cong Wang , Martin Rusko , netdev To: Vlad Yasevich Return-path: Received: from mail-pa0-f45.google.com ([209.85.220.45]:34114 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935147AbaH0SmO (ORCPT ); Wed, 27 Aug 2014 14:42:14 -0400 Received: by mail-pa0-f45.google.com with SMTP id eu11so929064pac.32 for ; Wed, 27 Aug 2014 11:42:14 -0700 (PDT) In-Reply-To: <53FE1AC3.5030409@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 27 Aug 2014 13:52:03 -0400 Vlad Yasevich wrote: > On 08/27/2014 01:28 PM, Cong Wang wrote: > > On Wed, Aug 27, 2014 at 10:06 AM, Martin Rusko wrote: > >> > >> I'm wondering, where is the proper place to fix this. Should > >> arp_create() function allocate skb big enough to produce ethernet > >> frame with at least minimum size? Or is it somewhere in NIC drivers > >> where small packets are padded with zeros? > > > > Drivers do that, for example e1000: > > > > /* On PCI/PCI-X HW, if packet size is less than ETH_ZLEN, > > * packets may get corrupted during padding by HW. > > * To WA this issue, pad all small packets manually. > > */ > > if (skb->len < ETH_ZLEN) { > > if (skb_pad(skb, ETH_ZLEN - skb->len)) > > return NETDEV_TX_OK; > > skb->len = ETH_ZLEN; > > skb_set_tail_pointer(skb, ETH_ZLEN); > > } > > > I think vxlan needs something like this: > > From: Vladislav Yasevich > Date: Wed, 27 Aug 2014 13:39:32 -0400 > Subject: [PATCH] vxlan: Pad short ethernet frames. > > If sending short ethernet frames from the vxlan device, pad > them to minimum size so they can be forwarded after decapsulation. > > Reported-by: Martin Rusko > Signed-off-by: Vladislav Yasevich > --- > drivers/net/vxlan.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c > index 1fb7b37..48267d4 100644 > --- a/drivers/net/vxlan.c > +++ b/drivers/net/vxlan.c > @@ -1939,6 +1939,14 @@ static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct > net_device *dev) > #endif > } > > + /* Pad short frames so they can be forwarded after decapsulation */ > + if (skb->len < ETH_ZLEN) { > + if (skb_pad(skb, ETH_ZLEN - skb->len)) > + return NETDEV_TX_OK; > + skb->len = ETH_ZLEN; > + skb_set_tail_pointer(skb, ETH_ZLEN); > + } > + > f = vxlan_find_mac(vxlan, eth->h_dest); > did_rsc = false; > No. The short frame is perfectly valid, over the VXLAN. The system doing the decap and forwarding should be where any padding is added if necessary.