Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756527AbcK3Ie0 (ORCPT ); Wed, 30 Nov 2016 03:34:26 -0500 Received: from tama500.ecl.ntt.co.jp ([129.60.39.148]:55274 "EHLO tama500.ecl.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751227AbcK3IeT (ORCPT ); Wed, 30 Nov 2016 03:34:19 -0500 X-Greylist: delayed 4031 seconds by postgrey-1.27 at vger.kernel.org; Wed, 30 Nov 2016 03:34:18 EST Subject: Re: [patch net / RFC] net: fec: increase frame size limitation to actually available buffer References: <1480444528-30054-1-git-send-email-nikita.yoush@cogentembedded.com> From: Toshiaki Makita Message-ID: Date: Wed, 30 Nov 2016 16:25:30 +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" X-TM-AS-MML: disable Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1431 Lines: 33 On 2016/11/30 15:36, Nikita Yushchenko wrote: >> But I think it is not necessary since the driver don't support jumbo frame. > > Hardcoded 1522 raises two separate issues. > > (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. > > Clean solution for this must take into account that difference between > MTU and max frame size is no longer known at compile time. Actually this > is the case even without DSA, due to VLANs: max frame size is (MTU + 18) > without VLANs, but (MTU + 22) with VLANs. However currently drivers tend > to ignore this and hardcode 22. With DSA, 22 is not enough, need to add > switch-specific tag size to that. > > Not yet sure how to handle this. DSA-specific API to find out tag size > could be added, but generic solution should handle all cases of dynamic > difference between MTU and max frame size, not only 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. Regards, Toshiaki Makita