Skip to content
  • Scott Feldman's avatar
    net: Add netlink support for virtual port management (was iovnl) · 57b61080
    Scott Feldman authored
    
    
    Add new netdev ops ndo_{set|get}_vf_port to allow setting of
    port-profile on a netdev interface.  Extends netlink socket RTM_SETLINK/
    RTM_GETLINK with two new sub msgs called IFLA_VF_PORTS and IFLA_PORT_SELF
    (added to end of IFLA_cmd list).  These are both nested atrtibutes
    using this layout:
    
                  [IFLA_NUM_VF]
                  [IFLA_VF_PORTS]
                          [IFLA_VF_PORT]
                                  [IFLA_PORT_*], ...
                          [IFLA_VF_PORT]
                                  [IFLA_PORT_*], ...
                          ...
                  [IFLA_PORT_SELF]
                          [IFLA_PORT_*], ...
    
    These attributes are design to be set and get symmetrically.  VF_PORTS
    is a list of VF_PORTs, one for each VF, when dealing with an SR-IOV
    device.  PORT_SELF is for the PF of the SR-IOV device, in case it wants
    to also have a port-profile, or for the case where the VF==PF, like in
    enic patch 2/2 of this patch set.
    
    A port-profile is used to configure/enable the external switch virtual port
    backing the netdev interface, not to configure the host-facing side of the
    netdev.  A port-profile is an identifier known to the switch.  How port-
    profiles are installed on the switch or how available port-profiles are
    made know to the host is outside the scope of this patch.
    
    There are two types of port-profiles specs in the netlink msg.  The first spec
    is for 802.1Qbg (pre-)standard, VDP protocol.  The second spec is for devices
    that run a similar protocol as VDP but in firmware, thus hiding the protocol
    details.  In either case, the specs have much in common and makes sense to
    define the netlink msg as the union of the two specs.  For example, both specs
    have a notition of associating/deassociating a port-profile.  And both specs
    require some information from the hypervisor manager, such as client port
    instance ID.
    
    The general flow is the port-profile is applied to a host netdev interface
    using RTM_SETLINK, the receiver of the RTM_SETLINK msg communicates with the
    switch, and the switch virtual port backing the host netdev interface is
    configured/enabled based on the settings defined by the port-profile.  What
    those settings comprise, and how those settings are managed is again
    outside the scope of this patch, since this patch only deals with the
    first step in the flow.
    
    Signed-off-by: default avatarScott Feldman <scofeldm@cisco.com>
    Signed-off-by: default avatarRoopa Prabhu <roprabhu@cisco.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    57b61080