[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <238161C5-A583-42E7-AE40-34314D22F31E@earthlink.net>
Date: Sun, 13 Jun 2010 23:19:06 -0700
From: Mitchell Erblich <erblichs@...thlink.net>
To: YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
Cc: David Miller <davem@...emloft.net>, xiaosuo@...il.com,
kuznet@....inr.ac.ru, pekkas@...core.fi, jmorris@...ei.org,
kaber@...sh.net, netdev@...r.kernel.org
Subject: Re: [PATCH] fragment: add fast path
On Jun 13, 2010, at 10:15 PM, YOSHIFUJI Hideaki wrote:
> David Miller wrote:
>>> As the fragments are usually in order,
>> In what universe does this happen "usually"?
>> Linux has been outputting fragments in reverse order for more than 10
>> years.
>> I'm not applying this patch.
>
> Dave, I know we've been sending in reverse order, of course.
> And, as far as I know, it seems Linux is the only implementation
> which sends fragments in reverse order.
>
> This is receiving side. I think we should accept the fact
> that Linux is not the only implementation, no?
>
> --yoshfuji
Group,
With respect to IPv4 and PATH MTU, aren't we
unlikely to generate packet frags?
With respect to IPv6, aren't frags are less likely
(intermediate nodes are not allowed to frag
(rfc 2460, sect 4.5 Frag header)) as I would
expect the source to use the PATH MTU?
Thus, a faster path is to support the largest Jumbo
MTUs (MTU >=9000: 16,110 : 14,336 : 10,240)
where possible for bulk data transfers with
proper page orders, IMO.
Mitchell Erblich
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists