From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B548C43381 for ; Fri, 1 Mar 2019 12:24:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5AA3D20851 for ; Fri, 1 Mar 2019 12:24:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="sD8iPnHS" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732784AbfCAMY1 (ORCPT ); Fri, 1 Mar 2019 07:24:27 -0500 Received: from mail-lj1-f196.google.com ([209.85.208.196]:46428 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727052AbfCAMYW (ORCPT ); Fri, 1 Mar 2019 07:24:22 -0500 Received: by mail-lj1-f196.google.com with SMTP id v16so20181083ljg.13 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=ftoxzl/REUgs/HQiid+RLtFtfAzxQpA1ilHQ4MnBAYi4h4Jifgq1IuiDyowJ5YcwY9 VQrJfp9B5vSxhrLmN3TImjxLJYUclxfxgav7G3UQGrSLWn7qoLCzgEiycQuiXrYBvo6M 2zWGFU04W4yRcpKub0NjVnprREk/Ayr+o3BkzZNtM1QG2CBjBZnFqBUjIfo/ppZIZSh6 ZaurZUvxJO6pJ9z+p3LrRovnScbmDlg22t/97HJk3Sy3k2aO9ZwEq3cZJFNtXiAAxJxB afyhoDjP1tCS6OlLpfXbkbyXvLbXre2PCY1upKxYbv6WvP4JnzuSJwSxoz2Pb4GtQO13 BFrQ== X-Gm-Message-State: APjAAAVuEOyxjbioKBTM7NRtZ2l165pf/0FXCIEA/InpZho4mMei7hyz XnLjgoj3j/slyXaC/TPksIlx0w== X-Google-Smtp-Source: APXvYqy/0ttijmehCNG2+JaHck0co7wO1F4vaB8BiOVs0SewBHHzCZpNKQC5z4ZrTVflTGnxz7R61g== 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: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@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