Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1477031pxu; Fri, 16 Oct 2020 13:02:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw0hCp+PZMpWXA89f4A/EHfcX7DmL07wmMTWXJ72XYK3m+3heqyL0TLC7SY0sBbHhMZIafg X-Received: by 2002:aa7:d781:: with SMTP id s1mr6094854edq.102.1602878533752; Fri, 16 Oct 2020 13:02:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602878533; cv=none; d=google.com; s=arc-20160816; b=UMeCoFVKE7kLBNK2wZ96j8H0WV4xXu+OOkRRIyXrxyeZtLmmqysfHcbdqxfiX41yl+ 0GWD+ncNPqegMREVxX045UeusoS62usmPnJ1p009gx5y/gbpwoqEV+C9mvt+XCAzFAum wxdVmWGsWn3vNQSzz1156T7+J3YfgrT9tswSyJ7oYairGrw7XysYuk9IJKaKnfiRPnm2 EVXdxXdVeedNLWDKpdAGhLYA/DKfg/Py9b4Op45qli+wjoU4mPCYUZzZxnzheQ6ybyZx RClkNHiYp2WS3YmfTjijbtGynTpF1qU1jSEzJGiym+abqCMs3vx3FQ9AGHEynlCbhr98 QGbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=sDq0K3fF7GgG2kV6httUCz2asgU66/3Zi+4Eq3K5PV8=; b=dL8OAkepHUs0VDlezHx0K7yNC/8FttfwDz5gpEHuPLhEoD44vKYqiwzxnuzQHOafGi ez4W9RpkaEOgnZhPB5PQtqvBGoP+GwIOLYoQLXzKoYUA+F5pE2DXm1j/W2Cr0q5VclkY YYGwYTzk6uJqx5nftmzFrOITQkYbJxN0AsnfXyRIfBcgphF6dyYHP9asEluKWLbhnnc2 +EoMCOiS3JH4PG4DI1CEfLPUyRKQaEUalV3XATFRN7OFcP7UaSIZ82wQXzb8rq5vIbcP kxP4/ovq24hY13ibJ1le/Ejtxs7WZ5xwLDcca3xcXSPh1nIxttp0qm2FR4ZgNSg++qdi 4I+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=LpD5TMU1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ng7si2110962ejb.699.2020.10.16.13.01.51; Fri, 16 Oct 2020 13:02:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=LpD5TMU1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404004AbgJPSwY (ORCPT + 99 others); Fri, 16 Oct 2020 14:52:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:34934 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2403993AbgJPSwY (ORCPT ); Fri, 16 Oct 2020 14:52:24 -0400 Received: from kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com (c-67-180-217-166.hsd1.ca.comcast.net [67.180.217.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 48FE42065C; Fri, 16 Oct 2020 18:52:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602874342; bh=A7zZGWRfTPgHv2W/P7bhldL+fcnGv2TC7ECKIEEdj/A=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=LpD5TMU1EAv09SqpvGHXT4gQ1YaI+jT2qxNutul3CbPeWLD2p+uC03AqOgjB6Bjds MSLjcQeA8Wl+D0DCEPxgkR7F9T+2/XNrg5CG8B1+iHfJPQ4yjopdt0/M9WO4nm5yIn Z+IWdjeeIuiNwYYuTHRTdOYyElGuKrVnMBX4Vqg4= Date: Fri, 16 Oct 2020 11:52:20 -0700 From: Jakub Kicinski To: Vladimir Oltean Cc: Christian Eggers , Kurt Kanzenbach , Woojung Huh , Andrew Lunn , Vivien Didelot , Florian Fainelli , Microchip Linux Driver Support , "David S . Miller" , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net] net: dsa: ksz: fix padding size of skb Message-ID: <20201016115220.771c7169@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <20201016181319.2jrbdp5h7avzjczj@skbuf> References: <20201014161719.30289-1-ceggers@arri.de> <4467366.g9nP7YU7d8@n95hx1g2> <20201016090527.tbzmjkraok5k7pwb@skbuf> <1655621.YBUmbkoM4d@n95hx1g2> <20201016155645.kmlehweenqdue6q2@skbuf> <20201016110311.6a43e10d@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20201016181319.2jrbdp5h7avzjczj@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 16 Oct 2020 21:13:19 +0300 Vladimir Oltean wrote: > On Fri, Oct 16, 2020 at 11:03:11AM -0700, Jakub Kicinski wrote: > > On Fri, 16 Oct 2020 18:56:45 +0300 Vladimir Oltean wrote: > > > > 3. "Manually" unsharing in dsa_slave_xmit(), reserving enough tailroom > > > > for the tail tag (and ETH_ZLEN?). Would moving the "else" clause from > > > > ksz_common_xmit() to dsa_slave_xmit() do the job correctly? > > > > > > I was thinking about something like that, indeed. DSA knows everything > > > about the tagger: its overhead, whether it's a tail tag or not. The xmit > > > callback of the tagger should only be there to populate the tag where it > > > needs to be. But reallocation, padding, etc etc, should all be dealt > > > with by the common DSA xmit procedure. We want the taggers to be simple > > > and reuse as much logic as possible, not to be bloated. > > > > FWIW if you want to avoid the reallocs you may want to set > > needed_tailroom on the netdev. > > Tell me more about that, I've been meaning since forever to try it out. > I read about needed_headroom and needed_tailroom, and it's one of the > reasons why I added the .tail_tag option in the DSA tagger (to > distinguish whether a switch needs headroom or tailroom), but I can't > figure out, just from static analysis of the code, where exactly is the > needed tailroom being accounted for. My understanding that the tail tag use case matches pretty well, needed_tailroom is supposed to be a hit to the higher layers of the stack to leave some extra space at the end. Now, it's probably of limited use in practice since I'd imagine most data comes in fragments. > For example, if I'm in Christian's > situation, e.g. I have a packet smaller than ETH_ZLEN, would the > tailroom be enough to hold just the dev->needed_tailroom, or would there > be enough space in the skb for the entire ETH_ZLEN + dev->needed_tailroom? I don't think we account for padding in general. Also looking at __pskb_pull_tail() we're already seem to be provisioning some extra 128B. So I guess it won't matter and the DSA tags are too small to need the head/tailroom hints anyway..