* [B.A.T.M.A.N.] [PATCH] batman-adv: decrease maximum fragment size
@ 2017-01-29 5:14 Linus Lüssing
2017-01-31 11:07 ` Sven Eckelmann
0 siblings, 1 reply; 3+ messages in thread
From: Linus Lüssing @ 2017-01-29 5:14 UTC (permalink / raw
To: b.a.t.m.a.n
From: Matthias Schiffer <mschiffer@universe-factory.net>
With this patch the maximum fragment size is reduced from 1400 to 1280
bytes.
Fragmentation v2 correctly uses the smaller of 1400 and the interface
MTU, thus generally supporting interfaces with an MTU < 1400 bytes, too.
However, currently "Fragmentation v2" does not support re-fragmentation.
Which means that once a packet is split into two packets of 1400 + x
bytes for instance and the next hop provides an interface with an even
smaller MTU of 1280 bytes, then the larger fragment is lost.
A maximum fragment size of 1280 bytes is a safer option as this is the
minimum MTU required by IPv6, making interfaces with an MTU < 1280
rather exotic.
Regarding performance, this should have no negative impact on unicast
traffic: Having some more bytes in the smaller and some less in the
larger does not change the sum of both fragments.
Concerning TT, choosing 1280 bytes fragments might result in more TT
messages than necessary when a large network is bridged into batman-adv.
However, the TT overhead in general is marginal due to its reactive
nature, therefore such a performance impact on TT should not be
noticeable for a user.
Cc: Matthias Schiffer <mschiffer@universe-factory.net>
[linus.luessing@c0d3.blue: Added commit message]
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
---
This patch is currently used in Gluon [1] because we stumbled over this
issue in setups where batman-adv first fragmented to 1400 bytes for a
wired, 1500B MTU connection and the larger fragment then being lost on
the next hop's VPN interface with an MTU of 1280 bytes.
[1]: https://github.com/freifunk-gluon/gluon/tree/master/patches/packages/routing
net/batman-adv/main.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/main.h b/net/batman-adv/main.h
index 57a8103..81c6a38 100644
--- a/net/batman-adv/main.h
+++ b/net/batman-adv/main.h
@@ -168,7 +168,7 @@ enum batadv_uev_type {
/* Maximum number of fragments for one packet */
#define BATADV_FRAG_MAX_FRAGMENTS 16
/* Maxumim size of each fragment */
-#define BATADV_FRAG_MAX_FRAG_SIZE 1400
+#define BATADV_FRAG_MAX_FRAG_SIZE 1280
/* Time to keep fragments while waiting for rest of the fragments */
#define BATADV_FRAG_TIMEOUT 10000
--
2.1.4
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [B.A.T.M.A.N.] [PATCH] batman-adv: decrease maximum fragment size
2017-01-29 5:14 [B.A.T.M.A.N.] [PATCH] batman-adv: decrease maximum fragment size Linus Lüssing
@ 2017-01-31 11:07 ` Sven Eckelmann
2017-01-31 20:39 ` Linus Lüssing
0 siblings, 1 reply; 3+ messages in thread
From: Sven Eckelmann @ 2017-01-31 11:07 UTC (permalink / raw
To: b.a.t.m.a.n
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
On Sonntag, 29. Januar 2017 06:14:28 CET Linus Lüssing wrote:
[...]
> However, currently "Fragmentation v2" does not support re-fragmentation.
> Which means that once a packet is split into two packets of 1400 + x
> bytes for instance and the next hop provides an interface with an even
> smaller MTU of 1280 bytes, then the larger fragment is lost.
[...]
Beside this change, did you try to make the fragments more equally sized?
Here is just some really ugly and untested pseudo code:
@@ -454,7 +454,7 @@ int batadv_frag_send_packet(struct sk_buff *skb,
struct sk_buff *skb_fragment;
unsigned int mtu = neigh_node->if_incoming->net_dev->mtu;
unsigned int header_size = sizeof(frag_header);
- unsigned int max_fragment_size, max_packet_size;
+ unsigned int max_fragment_size, num_fragments;
int ret;
/* To avoid merge and refragmentation at next-hops we never send
@@ -462,10 +462,17 @@ int batadv_frag_send_packet(struct sk_buff *skb,
*/
mtu = min_t(unsigned int, mtu, BATADV_FRAG_MAX_FRAG_SIZE);
max_fragment_size = mtu - header_size;
- max_packet_size = max_fragment_size * BATADV_FRAG_MAX_FRAGMENTS;
+
+ if (skb->len == 0)
+ return -EINVAL;
+
+#define ceil_div(x, y) (1 + ((x - 1) / y))
+ num_fragments = ceil_div(skb->len, max_fragment_size);
+ max_fragment_size = ceil_div(skb->len, num_fragments);
+#undef ceil_div
/* Don't even try to fragment, if we need more than 16 fragments */
- if (skb->len > max_packet_size) {
+ if (num_fragments > BATADV_FRAG_MAX_FRAGMENTS) {
ret = -EAGAIN;
goto free_skb;
}
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [B.A.T.M.A.N.] [PATCH] batman-adv: decrease maximum fragment size
2017-01-31 11:07 ` Sven Eckelmann
@ 2017-01-31 20:39 ` Linus Lüssing
0 siblings, 0 replies; 3+ messages in thread
From: Linus Lüssing @ 2017-01-31 20:39 UTC (permalink / raw
To: Sven Eckelmann; +Cc: b.a.t.m.a.n
On Tue, Jan 31, 2017 at 12:07:24PM +0100, Sven Eckelmann wrote:
> On Sonntag, 29. Januar 2017 06:14:28 CET Linus Lüssing wrote:
> [...]
> > However, currently "Fragmentation v2" does not support re-fragmentation.
> > Which means that once a packet is split into two packets of 1400 + x
> > bytes for instance and the next hop provides an interface with an even
> > smaller MTU of 1280 bytes, then the larger fragment is lost.
> [...]
>
> Beside this change, did you try to make the fragments more equally sized?
> Here is just some really ugly and untested pseudo code:
Have thought about it initially but pushed it asided when I
noticed it would only help regarding the initial issue for the
unicast packets but not potentially large TTs.
But generally, I like the idea of making fragments more equally
sized :-).
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-01-31 20:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-01-29 5:14 [B.A.T.M.A.N.] [PATCH] batman-adv: decrease maximum fragment size Linus Lüssing
2017-01-31 11:07 ` Sven Eckelmann
2017-01-31 20:39 ` Linus Lüssing
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.