Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp421787imb; Fri, 1 Mar 2019 04:26:34 -0800 (PST) X-Google-Smtp-Source: APXvYqxImmniy7385Yu+K3pludPXD1TWxrkSLOD+0+9/3I0/xfbkyXcZQeYZ55Nt020YHpLWSQyQ X-Received: by 2002:a17:902:4c08:: with SMTP id a8mr5279997ple.294.1551443194904; Fri, 01 Mar 2019 04:26:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551443194; cv=none; d=google.com; s=arc-20160816; b=ATiUsdxM+PGmfcTFQgrYnavGxfNWANdJw55OwByEN75jVIdcipAdu0qiwOeSzV0/q1 dPijdrsak9eGysLDpqeY620gCd6mQDc4k7w5iOu/v/H0RaAmVurv1PjpSu+aiLQY8rl1 i8NUG4fGmsIAn/CLY9I5bSsB5TdtGvhpWt5ezmlT1MSqCpC/AEYogSRWZ7Bc6wpSP10I bH/6/0N1sEAT+4wh1wuHyd9fBJ5N3li1Ly4ykqngB1iQFF+egNqI7UOBoLXvKus3mswL avfd3Sjl0l5FZXXp8CA1q2WUdpYymLgNces9CwXLiTE62mDUeCYpbY5y5e9hKHVPBqrs zD5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature; bh=uGzU57ZD8T+noYxG8gG+gCUh+Az1jvKzxC6daRRGSrI=; b=GTJTCyYhSJnzTAuDTFdzUPczkVvX0IcV+f6fJ8hs/jhw/lWwsnbUSrADQVttG0rtCr BoA9lYwUJPenpY66xhSbBV2U0wOXmEG/BprKJW733QTQh3xvbfIqnFde+innQnu7S8l8 VJq7FH37Jc9BiaQGEsG52h6n64PQ6o0OMNC5iwDyYZ8ghs5DnAky9j/YXExi2Y/eeifV 5oPSyby6SGJtDln6VQPW6towQq6b7ykvSONDEIDXUJVhs+m+scWt6THyIkGnLQXl0Vkd D7e3/y7jyBxgTs0DqnqzRawXGU3HsqIlo/lSimbiMUvbjZBCAci1tGPHEX7E+jtsEOiJ /eOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=sD8iPnHS; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 38si20750641pld.62.2019.03.01.04.26.19; Fri, 01 Mar 2019 04:26:34 -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=@linaro.org header.s=google header.b=sD8iPnHS; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732304AbfCAMYW (ORCPT + 99 others); Fri, 1 Mar 2019 07:24:22 -0500 Received: from mail-lj1-f195.google.com ([209.85.208.195]:44330 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727199AbfCAMYW (ORCPT ); Fri, 1 Mar 2019 07:24:22 -0500 Received: by mail-lj1-f195.google.com with SMTP id q128so20177375ljb.11 for ; Fri, 01 Mar 2019 04:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=uGzU57ZD8T+noYxG8gG+gCUh+Az1jvKzxC6daRRGSrI=; b=sD8iPnHSTsHG+eW5+MIjCyphSok5LuqTf4UgqXxZv5VCH085dcvtctatB9ho7lbLfg dWYvV+8PHFTxmkoSala30YHklFcF5dV+8hujzMnps22nLDYGG3LAE8DfxPdF39UJJSKg dcAnlRhOuMVg2jTGMD7BdJXYw5DnFcDbh1JIilBQTg7w72WHPSuyfGqLAAOS3oIs+zzK TiWmQdlZQePe7gLqD/gPsz29BV8EakG6P19dDf34mDvOgJDq1Y9FXqeqKwyhijKrVNLA W6EXWD/bEEgkLskqjFD9WPqiTPLRNb+BmWdJqG28fGIWkF8gRZYaGr1OdMXLtcUpD2/x bgJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=uGzU57ZD8T+noYxG8gG+gCUh+Az1jvKzxC6daRRGSrI=; b=b/muz9EZFLycwIVXVGXFwbYTpAZlcTY8k2tg4F5LzNCpuVNVLKugJDAJGmo87dOxpm /mlCuFNo2wUknGYGOcgxcDLcpZP1vi7e6LLpFZZUQlyc6DfVqgMGsCl9kbv/7vvkxQGu 5KSRU8aojhvH3wYCeK1MEt06qLiUH0E1FfZPNogLIQ/aVaFUTtgPmDapQeXiOl1xF4wY 7b4KGWfdDYqcjjDF9+P7wQYt/GQEeBtmBawlQgecNSGTnRK2x0IOejT/YkLS0ZF7W6Pk GuuukAyZfqL2Hka7J5zceYqXebyF/+amryy91S2CslHHqPGiHFKv3YKb9APaaqAQgi9I 2sdw== X-Gm-Message-State: APjAAAXfh2wXM+yi+U8JakTSB7jdCg4ydcXYA/JzjNUkW+Zwc2/L8V2+ e37b++ayPW9Ms50Nztay2KHNPw== X-Received: by 2002:a2e:3211:: with SMTP id y17mr226806ljy.88.1551443060133; Fri, 01 Mar 2019 04:24:20 -0800 (PST) Received: from khorivan (59-201-94-178.pool.ukrtel.net. [178.94.201.59]) by smtp.gmail.com with ESMTPSA id p142sm5283304lfe.92.2019.03.01.04.24.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 01 Mar 2019 04:24:20 -0800 (PST) Date: Fri, 1 Mar 2019 14:24:17 +0200 From: Ivan Khoronzhuk To: Florian Fainelli Cc: davem@davemloft.net, grygorii.strashko@ti.com, linux-omap@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, jiri@mellanox.com, ilias.apalodimas@linaro.org Subject: Re: [PATCH net-next 2/6] net: 8021q: vlan_dev: add vid tag to addresses of uc and mc lists Message-ID: <20190301122417.GB4851@khorivan> Mail-Followup-To: Florian Fainelli , davem@davemloft.net, grygorii.strashko@ti.com, linux-omap@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, jiri@mellanox.com, ilias.apalodimas@linaro.org References: <20190226184556.16082-1-ivan.khoronzhuk@linaro.org> <20190226184556.16082-3-ivan.khoronzhuk@linaro.org> <72ecf925-f818-3d6b-4f96-b01daabd21f2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <72ecf925-f818-3d6b-4f96-b01daabd21f2@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 27, 2019 at 08:09:44PM -0800, Florian Fainelli wrote: > > >On 2/26/2019 10:45 AM, Ivan Khoronzhuk wrote: >> Update vlan mc and uc addresses with VID tag while propagating >> addresses to lower devices, do this only if address is not synced. >> It allows at end driver level to distinguish addresses belonging >> to vlan devices. >> >> Signed-off-by: Ivan Khoronzhuk >> --- > >[snip] > >> >> +u16 vlan_dev_get_addr_vid(struct net_device *dev, const u8 *addr) > >Having some kernel doc comment here would also be nice. yes can be: vlan_dev_get_addr_vid - get vlan id the address belongs to > >> +{ >> + u16 vid = 0; >> + >> + if (dev->vid_len != NET_8021Q_VID_TSIZE) >> + return vid; >> + >> + vid = addr[dev->addr_len]; >> + vid |= (addr[dev->addr_len + 1] & 0xf) << 8; > >This uses knowledge of the maximum VLAN ID is 4095, which is fine, might >be a good idea to add a check on VID not exceeding the maximum VLAN ID >number instead of doing a silent truncation? and then return -1, not sure, just because it's 0 or directly set by vlan layer and is verified anyway. But no harm to verify even it looks like redundancy. > >[snip] > >> +static void vlan_dev_align_addr_vid(struct net_device *vlan_dev) >> +{ >> + struct net_device *real_dev = vlan_dev_real_dev(vlan_dev); >> + struct netdev_hw_addr *ha; >> + >> + if (!real_dev->vid_len) >> + return; > >Should not this check be moved to dev_{mc,uc}_sync? It does not seem to >me like this would scale really well across different stacked devices >(VLAN, bond, macvlan) as well as underlying drivers (cpsw, dsa, etc.). >Or maybe the check should be if vlan_dev->vid_len > real_dev->vid_len -> >error, right? It shouldn't be part of netdev addr module, no any vlan_dev_vlan_id(vlan_dev) should be there. It's scaled becouse bond/team ...etc, are ethernet devices and have IVDF enabled while configuration. Address propagation always is from leafs to real root device, every underneeth device knows nothing about above, so check is only in one direction. -- Regards, Ivan Khoronzhuk