From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yang Yingliang Subject: Re: [PATCH net v4 1/2] net: sched: tbf: fix calculation of max_size Date: Tue, 3 Dec 2013 15:44:07 +0800 Message-ID: <529D8BC7.4050005@huawei.com> References: <1386041214-72744-1-git-send-email-yangyingliang@huawei.com> <1386041214-72744-2-git-send-email-yangyingliang@huawei.com> <1386046793.30495.12.camel@edumazet-glaptop2.roam.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: , , , , To: Eric Dumazet Return-path: Received: from szxga02-in.huawei.com ([119.145.14.65]:33312 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751145Ab3LCHog (ORCPT ); Tue, 3 Dec 2013 02:44:36 -0500 In-Reply-To: <1386046793.30495.12.camel@edumazet-glaptop2.roam.corp.google.com> Sender: netdev-owner@vger.kernel.org List-ID: On 2013/12/3 12:59, Eric Dumazet wrote: > On Tue, 2013-12-03 at 11:26 +0800, Yang Yingliang wrote: > >> + for (max_size = 0; max_size < MAX_PKT_LEN; max_size++) >> + if (psched_l2t_ns(&q->rate, max_size) > q->buffer) >> + break; >> + if (--max_size <= 0) >> + goto unlock_done; >> + > > This seems dubious. With your new code, max_size < 65536 > > Prior code had : > > for (n = 0; n < 256; n++) > if (rtab->data[n] > qopt->buffer) > break; > max_size = (n << qopt->rate.cell_log) - 1; > > So we could have much bigger max_size. > > The reason I ask is that its possible to have qdisc_pkt_len(skb) being > bigger than 65536, for TCP packets with low MSS value. > Hmmm, if qdisc_pkt_len(skb) is bigger than 65536, skb_is_gso(skb) is true, it will go into tbf_segment(). If I am wrong, please point me out, thanks! BTW, 65536 is suggested by Jesper, I'm a little uncertain about it. He is, too. Do you or some other developers have stronger opinions on this? Thanks! Yang