Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp568940imu; Tue, 27 Nov 2018 17:29:46 -0800 (PST) X-Google-Smtp-Source: AFSGD/UTS6Hv8oN9smrw3sPd3tidNamGtZYuOrpq9hTe9HXz/gs6meOUiIHpJZwk0P1NFR5ANnkm X-Received: by 2002:a17:902:4225:: with SMTP id g34mr35671484pld.152.1543368586830; Tue, 27 Nov 2018 17:29:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543368586; cv=none; d=google.com; s=arc-20160816; b=zsd5MqYDEVO33fevoJvS+46KQrYUxmgKb482+1SjdMVvhf+l0AHoGyBPFuEij4kCsm tNK1cxij2PyHYUwLk5ZoD6f4XRWlzYvbstM2UAvkjEdlcX68B/sWvxtGD8yWdsTvtV+h huQZ8iZwPhEOrvYTXJYjHLZBvqFFI2DHhBDZDbHuE3JYqMo0uVMP+UB7YKhum7qEuu2j YlTYoOyAPFJq70GoZk5l7mBMGXplWZEet2dSKwxRNLjgog0+HkonKYu0vya3TROEmawu ULSHVAzGy9wjOSiBowOeURxMrhC5eFkXXyrPY8qMsLPxQhwNCV7z3OhcHI12A9BU2UW+ LxmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=iL3WCl4ASjsA/ygQPkMwqi3EuwwGA75WXKbsT0nDFVM=; b=noSIDL0cZLsRn0mbnMoIOLOzvFno/SA6dqbzIy9/5llm9uqmS3z/sSAK3P4uM7+3I9 xNkkIjo74jmJ35fnB7zHx1+17i21LMQarvxVdsj8xRm2iT1lAVoG8TR1mJg+6EA2BUR/ D0dM97NXos80k31ln/1A9ZXsY+Nu9Vl4wfTTaAy6Wz5oCnOAqbLzK75FBzZTUYbEHWMu UQUXzhSxJ37QFtYo/yhgKWrUrkaSftIy4u1h9oshJ4ykF3KAj0VKz7Va3JSmk1BjL/kc tPFA5jQDAU7xHW0ltAICddJbJBgxCpRobtvNJwkXlBs+rXB7m6hAqWiDC8pAdV9/R8ZG dkNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=b8zoVDfm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 13si5604634pld.398.2018.11.27.17.29.31; Tue, 27 Nov 2018 17:29:46 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=b8zoVDfm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727165AbeK1M1M (ORCPT + 99 others); Wed, 28 Nov 2018 07:27:12 -0500 Received: from fllv0015.ext.ti.com ([198.47.19.141]:38528 "EHLO fllv0015.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726567AbeK1M1M (ORCPT ); Wed, 28 Nov 2018 07:27:12 -0500 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id wAS1RFFt096815; Tue, 27 Nov 2018 19:27:15 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1543368435; bh=iL3WCl4ASjsA/ygQPkMwqi3EuwwGA75WXKbsT0nDFVM=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=b8zoVDfmaLbMpv2jUDZ8LoUXv6CGfWbGnp2ZrPown+RzDwXA9hledJhCD53Im2Yoc sp1d0dYfyfAI6zVEVIDRZpw9qIwbwgFdkEj97mYjgPkdrhEy1ErAL/ufZv/GeEI2kv ORkUvg39t4ZyG7N2Ef7Gn7o9fNlRLV5GJbx3LUcI= Received: from DFLE114.ent.ti.com (dfle114.ent.ti.com [10.64.6.35]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id wAS1RFog065811 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 27 Nov 2018 19:27:15 -0600 Received: from DFLE105.ent.ti.com (10.64.6.26) by DFLE114.ent.ti.com (10.64.6.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Tue, 27 Nov 2018 19:27:15 -0600 Received: from dlep32.itg.ti.com (157.170.170.100) by DFLE105.ent.ti.com (10.64.6.26) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1591.10 via Frontend Transport; Tue, 27 Nov 2018 19:27:15 -0600 Received: from [128.247.59.147] (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep32.itg.ti.com (8.14.3/8.13.8) with ESMTP id wAS1RFSE011241; Tue, 27 Nov 2018 19:27:15 -0600 Subject: Re: [PATCH] net: ethernet: ti: cpsw: allow to configure min tx packet size To: Andrew Lunn CC: "David S. Miller" , , Sekhar Nori , , References: <20181125234315.28313-1-grygorii.strashko@ti.com> <20181126022711.GD32164@lunn.ch> From: Grygorii Strashko Message-ID: <7a194258-2888-2268-42d1-27ac513a5c8a@ti.com> Date: Tue, 27 Nov 2018 19:27:15 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181126022711.GD32164@lunn.ch> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andrew, On 11/25/18 8:27 PM, Andrew Lunn wrote: > On Sun, Nov 25, 2018 at 05:43:15PM -0600, Grygorii Strashko wrote: >> For proper VLAN packets forwarding CPSW driver uses min tx packet size of >> 64bytes (VLAN_ETH_ZLEN, excluding ETH_FCS) which was corrected by >> commit 9421c9015047 ("net: ethernet: ti: cpsw: fix min eth packet size"). >> >> Unfortunately, this breaks some industrial automation protocols, as >> reported by TI customers [1], which can work only with min TX packet size >> from 60 byte (ecluding FCS). > > Hi Grygorii > > excluding... > >> Hence, introduce module boot parameter "tx_packet_min" to allow configure >> min TX packet size at boot time. > > Module parameters are generally not liked. not sure how to proceed otherwise. There is always one instance of CPSW per SoC, so Module parameter is safe here at least. > > What actually happens here with this lower limit? Does the hardware > send runt packets? Does the protocol actually require runt packets? I do not have more details in addition to what's described in [1]: "While for instance the ARP protocol does not seem to have a problem with additional padding in the payload, some industrial automation protocols seem to be strict in this regard." "We're basically running a bridge for different industrial protocols like ProfiNet" As per my understanding there some industrial HW and SW which has very strict limitation to min packet size and just can't handle other min packet sizes. > > I'm just wondering if the module parameter can be avoided by setting > this as the default. It was a default value 60 bytes (64 bytes with FCS), but I changed it to 64 byte (68 byte with FCS) as per above mentioned commit for proper VLAN tagged packets forwarding support (which seems legal as per 802.1q - G.2.1 Treatment of PAD fields in IEEE 802.3 frames). Use case: - Port 0 (int) - vlan capable host. - Port 1 (ext) - vlan capable network - port 2 (ext)- non vlan capable network. pvid is set. all egress traffic untagged. CPSW HW can't align packet properly when vlan tag is removed, so need to use 68 byte min packet size. Hence, both use cases need to be supported - this patch posted. without it TI customers will continue do revert manually when required which definitely not a good option. >But we need to ensure ARP packets, which are > smaller than the minimum MTU are correctly padded. [1] https://e2e.ti.com/support/arm/sitara_arm/f/791/t/701669 -- regards, -grygorii