From: "Henrik Lindström" <lindstrom515@gmail.com>
To: Florian Westphal <fw@strlen.de>
Cc: Florian Westphal <fw@strlen.de>,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: macvtap performs IP defragmentation, causing MTU problems for virtual machines
Date: Thu, 05 Oct 2023 19:25:53 +0200 [thread overview]
Message-ID: <3259970.44csPzL39Z@pc> (raw)
In-Reply-To: <20231004080037.GC15013@breakpoint.cc>
On onsdag 4 oktober 2023 10:00:37 CEST Florian Westphal wrote:
> Can you submit this formally, with proper changelog and Signed-off-by?
> See scripts/checkpatch.pl in the kernel tree.
Sure, i can give it a shot. How do i properly credit you if i submit your
patch with some small changes of my own?
> You could also mention in changelog that this is ipv4 only because
> ipv6 already considers the interface index during reassembly.
Interesting. I've been trying to understand the code and it seems like
ipv6 does defragmentation per-interface, while ipv4 does it "per-vrf"
(correct me if i'm wrong). Is there any reason for this difference?
I also did some more testing with the diff from my previous mail. It
looks like the problem remains for interfaces under vrfs. I think simply
doing the bcast/mcast check first fixes that though, something like this:
if (skb->pkt_type == PACKET_BROADCAST || skb->pkt_type == PACKET_MULTICAST) {
if (dev)
return dev->ifindex;
}
return l3mdev_master_ifindex_rcu(dev);
Does that look reasonable?
The idea being that bcast/mcast packets are always defragmented
per-interface, and unicast packets always "per-vrf".
Thanks,
Henrik
next prev parent reply other threads:[~2023-10-05 17:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-30 16:00 macvtap performs IP defragmentation, causing MTU problems for virtual machines Henrik Lindström
2023-10-02 9:20 ` Florian Westphal
2023-10-02 18:49 ` Henrik Lindström
2023-10-04 8:00 ` Florian Westphal
2023-10-05 17:25 ` Henrik Lindström [this message]
2023-10-06 6:06 ` Florian Westphal
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=3259970.44csPzL39Z@pc \
--to=lindstrom515@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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.