Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758227AbcLAMtC (ORCPT ); Thu, 1 Dec 2016 07:49:02 -0500 Received: from tama50.ecl.ntt.co.jp ([129.60.39.147]:59065 "EHLO tama50.ecl.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751423AbcLAMtA (ORCPT ); Thu, 1 Dec 2016 07:49:00 -0500 Subject: Re: DSA vs envelope frames References: <1480444528-30054-1-git-send-email-nikita.yoush@cogentembedded.com> From: Toshiaki Makita Message-ID: <344d53f8-1365-b478-ad81-44722932de91@lab.ntt.co.jp> Date: Thu, 1 Dec 2016 21:46:58 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit To: Nikita Yushchenko , Andy Duan , "David S. Miller" , Troy Kisky , Andrew Lunn , Eric Nelson , Philippe Reynes , Johannes Berg , "netdev@vger.kernel.org" Cc: Chris Healy , Fabio Estevam , "linux-kernel@vger.kernel.org" , Vivien Didelot , lorian Fainelli X-TM-AS-MML: disable Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2181 Lines: 53 On 2016/11/30 23:58, Nikita Yushchenko wrote: >>> (1) When DSA is in use, frames processed by FEC chip contain DSA tag and >>> thus can be larger than hardcoded limit of 1522. This issue is not >>> FEC-specific, any driver that hardcodes maximum frame size to 1522 (many >>> do) will have this issue if used with DSA. >> >> BTW I'm trying to introduce envelope frames to solve this kind of problems. >> http://marc.info/?t=147496691500005&r=1&w=2 >> http://marc.info/?t=147496691500003&r=1&w=2 >> http://marc.info/?t=147496691500002&r=1&w=2 >> http://marc.info/?t=147496691500004&r=1&w=2 >> http://marc.info/?t=147496691500001&r=1&w=2 >> >> It needs jumbo frame support of NICs though. > > Thanks for pointing to this. > > Indeed frame with DSA tag conceptually is an envelope frame. > > ndev->env_hdr_len introduced by your patches, actually is explicitly > handled difference between (MTU + 18) and frame that HW should allow. > If this is known, hardware can be configured to work with DSA. At least > FEC hardware that can send and receive "slightly larger" frames after > simple register configuration. > > Furthermore, since DSA configuration is known statically (it comes from > device tree), ndo_set_env_hdr_len method could be automatically called > at init, making setup working by default if driver supports that. And if > not, perhaps can automatically lower MTU. > > Looks like a solution :) > > What's current status of this work? Thank you for taking a look. I'm planning to post v2 soon. > What is not really clear - what if several tagging protocols are used > together. AFAIU, things may be more complex that simple appending of > tags, e.g. EDSA tag can carry VLAN id inside. If kernel is aware of VLAN configuration, add 4 bytes + DSA tag size. (I'm not familiar with how dsa knows vlan configuration, but probably through switchdev_port_obj_add()? If so, dsa should be able to take into account additional vlan tag size.) If vlan tag is opaque from kernel, e.g. forwarding vlan tagged frames without configuring vlan_filtering in bridge, admin needs to set env_hdr_len manually. This is why I'm proposing manual operation. Regards, Toshiaki Makita