[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.20.1607081340430.26593@stoner.jakma.org>
Date: Fri, 8 Jul 2016 13:55:11 +0100 (BST)
From: Paul Jakma <paul@...ma.org>
To: Alan Davey <Alan.Davey@...aswitch.com>
cc: David Miller <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"kuznet@....inr.ac.ru" <kuznet@....inr.ac.ru>,
"jmorris@...ei.org" <jmorris@...ei.org>,
"yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>,
"kaber@...sh.net" <kaber@...sh.net>
Subject: RE: [PATCH] net: Fragment large datagrams even when IP_HDRINCL is
set.
On Wed, 15 Jun 2016, Alan Davey wrote:
> The only case that would break is that where an application relies on
> the existing (documented as a bug) feature of getting an EMSGSIZE
> return code in the case of an over-sized packet. Applications that
> perform their own fragmentation would be unaffected.
If this doesn't break existing applications that are doing fragmentation
in userspace on raw sockets (e.g. Quagga ospfd), that's better.
As per previous email, I'd love to be able to get rid of that code and
have the kernel do it for me. However, I also don't want to have to do
anything other non-trivial to that code either. :)
The issue for us is, how would we know on any given host whether the
kernel will do the fragmentation or whether ospfd has to do it? We need
to be able to probe for that capability, surely?
I guess "send an oversized packet and see if we get EMSGSIZE comes back
or not" could be one way, though the 'man 7 raw' man page ony my system
says that is returned on raw socket if the /IP/ max size (64 KiB) is
exceeded - it doesn't say anything about that being returned if output
MTU is exceeded. Also, that implies a failed packet send on startup on
older kernels and having to rejiggle the packet we've constructed to
retry.
Some kind of "I want kernel to do the fragmentation" sockopt, that was
guaranteed to error with ENOPROTOOPT on non-implementing kernels, that
we could try set when creating the socket, would seem simpler/nicer from
my POV of my corner of user-space.
?
regards,
--
Paul Jakma | paul@...ma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
It would be nice to be sure of anything the way some people are of everything.
Powered by blists - more mailing lists