sched: scatter-gathering and generic-receiving-offloading features in network driver break the rate limiting/shaping.

sched: scatter-gathering and generic-receiving-offloading features in network driver break the rate limiting/shaping.

[YANG Zhe]

Hi there,

When these options is on, kernel sends/receives skb with length
greater than normal (1500 + link-layer overhead). It's because several
consecutive TCP segments is merged into a single large skb, and the
network card is responsible for splitting/merging it. For example:
http://i.imgur.com/wnv98.png , http://i.imgur.com/WPwjE.png .

Some scheduler my drop the packet because its qdisc_skb_len() is large
than its max_size(buffer/tokens), which implies that the scheduler
can't send this packet at once, so that it must be dropped on
enqueue()ing. The qdisc_rate_table used in calculation of consumed
time also fails because of its small size (u32[256]). Since the only
limit of the skb is the 64k limitation on ip_totlen, if we keep using
the u32[256] table, the cell_log would be quite large hence the time
calculation would be quite inaccurate.

Also, when calculating the time to send the merged skb, it's better to
calculate how many packets it will break into, however it may not be
accurate because of different MSS in different stream. Some weird
packet which should be fragmented on the IP layer may also have larger
size than normal and it's total size after breaking down is also
different.

I would recommend that token based scheduler should allow deficit, and
redesign the rate table, maybe leave some information in the skb to
indicate whether it is a gathered packet.

Thanks!

-- 
Sincerely,
    Yang Zhe