lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 11 Jun 2022 17:58:46 +0800
From:   Jiaqing Zhao <jiaqing.zhao@...ux.intel.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Samuel Mendoza-Jonas <sam@...dozajonas.com>,
        "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        openbmc@...ts.ozlabs.org
Subject: Re: [PATCH v2 0/6] Configurable VLAN mode for NCSI driver


On 2022-06-11 13:44, Jakub Kicinski wrote:
> On Sat, 11 Jun 2022 13:18:51 +0800 Jiaqing Zhao wrote:
>> All ncsi devices uses the same driver as they uses same command set,
>> so the driver doesn't know what modes are supported. And in current
>> driver, the vlan related parameters are configured when registering
>> the device, adding an ncsi-netlink command to do so seems to be
>> unsuitable.
> 
> Maybe you could draw a diagram? NC-SI is a bit confusing.

Yes I admit NC-SI is confusing as its design is not as straightforward
as the MAC-PHY structure. In NC-SI, there are two macs like below.

        Packets + NCSI commands                        Packets
    MAC-------------------------External controller MAC---------PHY

The NCSI commands are used to set the behavior of the External controller
MAC, like it's MAC address filter, VLAN filters. Those filtered packets
will be transferred back to the MAC.

Unlike PHY has standard registers to determine its model and capabilities,
NC-SI seems does not have such way.
>> And adding a netlink command requires extra application in userspace
>> to switch the mode. In my opinion, it would be more user-friendly to
>> make it usable on boot.
> 
> Unfortunately convenience is not reason to start adding system config
> into DT.

Currently there is already a DT config "use-ncsi" is used to choose using
MDIO PHY or NCSI stack in the MAC driver with NCSI support like ftgmac100.
That's why I choose adding another DT option here.

>> Netdev also does not work as the ncsi device itself does not have
>> its own netdev, the netdev comes from the mac device. For different
>> vlan modes, the netdev feature set of its parent mac device are the
>> same.
> 
> You say that, yet the command handling already takes into account the
> VLAN list:
> 
> 	if (list_empty(&ndp->vlan_vids)) {
> 
> which come from the MAC netdev. What's wrong with setting the filtering
> mode based on NETIF_F_HW_VLAN_CTAG_FILTER ?

When configuring the mac driver, there might be two net_device_ops sets
for MDIO or NC-SI. When using NC-SI, some features need to be delegated
to the external controller MAC, like VLAN hardware filtering, different
ndo_vlan_rx_{add,kill}_vid callbacks need to be assigned.

The filtering mode is an optional mode defined in NC-SI spec, some
devices does not support it. In this case, to support VLAN, I would
personally in favor of using the "Any VLAN" mode to let the external
MAC pass all packets to the internal one, and let the internal MAC
handle it either with its own hardware filter or software filter. In
this case, the VLAN list in NC-SI driver (used for setting the external
MAC filter) is not used.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ