netdev - Re: [PATCH net-next 6/8] devlink: introduce port's peer netdevs

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]

Message-ID: <20190301080547.09cc0a9a@cakuba.netronome.com>
Date:   Fri, 1 Mar 2019 08:05:47 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     davem@...emloft.net, oss-drivers@...ronome.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next 6/8] devlink: introduce port's peer netdevs

On Fri, 1 Mar 2019 08:37:00 +0100, Jiri Pirko wrote:
> >> >I do not think that every netdev should have a devlink port associated.
> >> >    
> >> >> Not sure about VF.
> >> >> 
> >> >> Consider a simple problem of setting up a VF mac address. In legacy, you
> >> >> do it like this:
> >> >> $ ip link set eth2 vf 1 mac 00:52:44:11:22:33
> >> >> However, in new model, you so far cannot do that.    
> >> >
> >> >Why?
> >> >
> >> >$ devlink port set pci/0000:82:00.0/10001 peer_eth_addr 00:52:44:11:22:33    
> >> 
> >> Yeah. That is not yet implemented. I agree it is most straightforward.
> >> The question is, is it fine to have set of:
> >> peer_eth_addr
> >> peer_mtu
> >> peer_something_else
> >> Or rather to have some object to pin this on. Something like:
> >> 
> >> $ devlink port peer set pci/0000:82:00.0/10001 eth_addr 00:52:44:11:22:33  
> >
> >I do like the object one better, would this mean I should restructure
> >the peer stuff somehow (netlink attribute structure)?  
> 
> Well we can introduce separate commands:
> DEVLINK_CMD_PORT_PEER_GET
> DEVLINK_CMD_PORT_PEER_SET
> 
> For "set" part, this would work nice. However for the "get" part, we
> would have to call both DEVLINK_CMD_PORT_GET and
> DEVLINK_CMD_PORT_PEER_GET. So probably better to add a nest attr:
> DEVLINK_ATTR_PORT_PEER
> and have attrs like:
> DEVLINK_ATTR_PORT_PEER_HW_ADDR  (does not have to be always eth, right?)
> DEVLINK_ATTR_PORT_PEER_TYPE (DEVLINK_PORT_TYPE_NOTSET/DEVLINK_PORT_TYPE_ETH/DEVLINK_PORT_TYPE_IB)
> DEVLINK_ATTR_PORT_PEER_NETDEV_IFINDEX
> DEVLINK_ATTR_PORT_PEER_NETDEV_NAME
> DEVLINK_ATTR_PORT_PEER_NETDEV_IBDEV_NAME
> in the nest.
> 
> The userspace part can stay as I described previously:
> $ devlink port peer set pci/0000:82:00.0/10001 hw_addr 00:52:44:11:22:33
> 
> Not sure about "port show" output. In json, the "peer" things should be
> under "peer" dictionary.

I'll make it so.