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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CANvbpLSdECzm+C1fZ4UBmQQvG+ocncqaTAWasKhruKvttBZEfw@mail.gmail.com>
Date:	Thu, 9 Aug 2012 21:56:05 +0800
From:	YANG Zhe <yangzhe1990@...il.com>
To:	netdev@...r.kernel.org
Subject: sched: scatter-gathering and generic-receiving-offloading features in
 network driver break the rate limiting/shaping.

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
--
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