netdev
[Top] [All Lists]

Re: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature

To: ravinandan.arakali@xxxxxxxxxxxx
Subject: Re: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Fri, 27 May 2005 12:02:15 -0700 (PDT)
Cc: jgarzik@xxxxxxxxx, netdev@xxxxxxxxxxx, raghavendra.koushik@xxxxxxxxxxxx, leonid.grossman@xxxxxxxxxxxx, ananda.raju@xxxxxxxxxxxx, rapuru.sriram@xxxxxxxxxxxx
In-reply-to: <000a01c562d9$9b661130$3910100a@xxxxxxxxxxx>
References: <20050526.164217.45745005.davem@xxxxxxxxxxxxx> <000a01c562d9$9b661130$3910100a@xxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
From: "Ravinandan Arakali" <ravinandan.arakali@xxxxxxxxxxxx>
Date: Fri, 27 May 2005 09:32:00 -0700

> Thanks for the quick feedback.
> At that time when we considered using skb_shinfo(skb)->fraglist,
> it contained fragments of MTU size. So, for a 60k udp datagram 
> and 1500 MTU we will have 60k/1500 = 45 fragments which is
> more than MAX_SKB_FRAGS(18).
> 
> However we will relook at fraglist for the possibility of increasing
> frag size to >MTU.

MAX_SKB_FRAGS controls the limit of skb_shinfo(skb)->frags[]
entries, not how many SKBs may be chained via
skb_shinfo(skb)->fraglist, there is no limit on the latter.

Note that there is much coalescing that can be performed on
the SKB list data areas, particularly if UDP sendfile() is
being used.

But such coalescing is messy to be performing inside of the
drivers.  It may end up being the case that your approach
ends up being a better one for these reasons.

<Prev in Thread] Current Thread [Next in Thread>