From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: skb length without fragments Date: Mon, 8 Oct 2018 11:23:05 -0700 Message-ID: <6b9500e2-b3eb-3c3c-3e52-d67ea0a7d51f@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit To: pradeep kumar nalla , netdev@vger.kernel.org Return-path: Received: from mail-pl1-f174.google.com ([209.85.214.174]:40076 "EHLO mail-pl1-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726393AbeJIBgG (ORCPT ); Mon, 8 Oct 2018 21:36:06 -0400 Received: by mail-pl1-f174.google.com with SMTP id 1-v6so10427628plv.7 for ; Mon, 08 Oct 2018 11:23:07 -0700 (PDT) In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 10/08/2018 11:02 AM, pradeep kumar nalla wrote: > Hi > > While testing my network driver with pktgen I could see an skb greater > than 16K without fragments in xmit function. This lead to a fix in my > driver that assumes when an SKB whose length is greater than 16K will > come with fragments. Apart from pktgen what are the chances or > possibilities of getting an SKB greater than 16K without fragments? . > When I tried with tools like iperf/iper3/netperf, didn’t see a single > incidence where the SKB length is greater than 16K and without frags. > Even socket layer I see function alloc_skb_with_frags, does this mean > all the larger packets come with frags. > There are cases where skb_linearize() calls happen, and then certainly can feed a driver with a big linear skb. Even if current tree would not hit this, you have to play safe and do the check in the driver.