| Message ID | 20210121085237.137919-1-saeed@kernel.org |
|---|---|
| Headers | show |
| Series | Add mlx5 subfunction support | expand |
On 1/21/2021 12:52 AM, Saeed Mahameed wrote: > From: Parav Pandit <parav@nvidia.com> > > Extended devlink interface for the user to add and delete a port. > Extend devlink to connect user requests to driver to add/delete > a port in the device. > > Driver routines are invoked without holding devlink instance lock. > This enables driver to perform several devlink objects registration, > unregistration such as (port, health reporter, resource etc) by using > existing devlink APIs. > This also helps to uniformly use the code for port unregistration > during driver unload and during port deletion initiated by user. > > Examples of add, show and delete commands: > $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev > > $ devlink port show > pci/0000:06:00.0/65535: type eth netdev ens2f0np0 flavour physical port 0 splittable false > > $ devlink port add pci/0000:06:00.0 flavour pcisf pfnum 0 sfnum 88 Do we need to specify pfnum when adding a SF port? Isn't this redundant? Isn't there a 1:1 mapping between the pci device and a pfnum? > pci/0000:06:00.0/32768: type eth netdev eth6 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false > function: > hw_addr 00:00:00:00:00:00 state inactive opstate detached > > $ devlink port show pci/0000:06:00.0/32768 > pci/0000:06:00.0/32768: type eth netdev eth6 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false > function: > hw_addr 00:00:00:00:00:00 state inactive opstate detached > > $ udevadm test-builtin net_id /sys/class/net/eth6 > Load module index > Parsed configuration file /usr/lib/systemd/network/99-default.link > Created link configuration context. > Using default interface naming scheme 'v245'. > ID_NET_NAMING_SCHEME=v245 > ID_NET_NAME_PATH=enp6s0f0npf0sf88 > ID_NET_NAME_SLOT=ens2f0npf0sf88 > Unload module index > Unloaded link configuration context. > > Signed-off-by: Parav Pandit <parav@nvidia.com> > Reviewed-by: Vu Pham <vuhuong@nvidia.com> > Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> > --- > include/net/devlink.h | 52 ++++++++++++++++++ > net/core/devlink.c | 121 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 173 insertions(+) > > diff --git a/include/net/devlink.h b/include/net/devlink.h > index dc3bf8000082..d8edd9a10907 100644 > --- a/include/net/devlink.h > +++ b/include/net/devlink.h > @@ -152,6 +152,17 @@ struct devlink_port { > struct mutex reporters_lock; /* Protects reporter_list */ > }; > > +struct devlink_port_new_attrs { > + enum devlink_port_flavour flavour; > + unsigned int port_index; > + u32 controller; > + u32 sfnum; > + u16 pfnum; > + u8 port_index_valid:1, > + controller_valid:1, > + sfnum_valid:1; > +}; > + > struct devlink_sb_pool_info { > enum devlink_sb_pool_type pool_type; > u32 size; > @@ -1362,6 +1373,47 @@ struct devlink_ops { > int (*port_function_hw_addr_set)(struct devlink *devlink, struct devlink_port *port, > const u8 *hw_addr, int hw_addr_len, > struct netlink_ext_ack *extack); > + /** > + * port_new() - Add a new port function of a specified flavor > + * @devlink: Devlink instance > + * @attrs: attributes of the new port > + * @extack: extack for reporting error messages > + * @new_port_index: index of the new port > + * > + * Devlink core will call this device driver function upon user request > + * to create a new port function of a specified flavor and optional > + * attributes > + * > + * Notes: > + * - Called without devlink instance lock being held. Drivers must > + * implement own means of synchronization > + * - On success, drivers must register a port with devlink core > + * > + * Return: 0 on success, negative value otherwise. > + */ > + int (*port_new)(struct devlink *devlink, > + const struct devlink_port_new_attrs *attrs, > + struct netlink_ext_ack *extack, > + unsigned int *new_port_index); > + /** > + * port_del() - Delete a port function > + * @devlink: Devlink instance > + * @port_index: port function index to delete > + * @extack: extack for reporting error messages > + * > + * Devlink core will call this device driver function upon user request > + * to delete a previously created port function > + * > + * Notes: > + * - Called without devlink instance lock being held. Drivers must > + * implement own means of synchronization > + * - On success, drivers must unregister the corresponding devlink > + * port > + * > + * Return: 0 on success, negative value otherwise. > + */ > + int (*port_del)(struct devlink *devlink, unsigned int port_index, > + struct netlink_ext_ack *extack); > }; > > static inline void *devlink_priv(struct devlink *devlink) > diff --git a/net/core/devlink.c b/net/core/devlink.c > index 4cbc02fb602d..541b5f549274 100644 > --- a/net/core/devlink.c > +++ b/net/core/devlink.c > @@ -1147,6 +1147,111 @@ static int devlink_nl_cmd_port_unsplit_doit(struct sk_buff *skb, > return devlink_port_unsplit(devlink, port_index, info->extack); > } > > +static int devlink_port_new_notifiy(struct devlink *devlink, > + unsigned int port_index, > + struct genl_info *info) > +{ > + struct devlink_port *devlink_port; > + struct sk_buff *msg; > + int err; > + > + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL); > + if (!msg) > + return -ENOMEM; > + > + mutex_lock(&devlink->lock); > + devlink_port = devlink_port_get_by_index(devlink, port_index); > + if (!devlink_port) { > + err = -ENODEV; > + goto out; > + } > + > + err = devlink_nl_port_fill(msg, devlink, devlink_port, > + DEVLINK_CMD_NEW, info->snd_portid, > + info->snd_seq, 0, NULL); > + if (err) > + goto out; > + > + err = genlmsg_reply(msg, info); > + mutex_unlock(&devlink->lock); > + return err; > + > +out: > + mutex_unlock(&devlink->lock); > + nlmsg_free(msg); > + return err; > +} > + > +static int devlink_nl_cmd_port_new_doit(struct sk_buff *skb, > + struct genl_info *info) > +{ > + struct netlink_ext_ack *extack = info->extack; > + struct devlink_port_new_attrs new_attrs = {}; > + struct devlink *devlink = info->user_ptr[0]; > + unsigned int new_port_index; > + int err; > + > + if (!devlink->ops->port_new || !devlink->ops->port_del) > + return -EOPNOTSUPP; > + > + if (!info->attrs[DEVLINK_ATTR_PORT_FLAVOUR] || > + !info->attrs[DEVLINK_ATTR_PORT_PCI_PF_NUMBER]) { > + NL_SET_ERR_MSG_MOD(extack, "Port flavour or PCI PF are not specified"); > + return -EINVAL; > + } > + new_attrs.flavour = nla_get_u16(info->attrs[DEVLINK_ATTR_PORT_FLAVOUR]); > + new_attrs.pfnum = > + nla_get_u16(info->attrs[DEVLINK_ATTR_PORT_PCI_PF_NUMBER]); > + > + if (info->attrs[DEVLINK_ATTR_PORT_INDEX]) { > + /* Port index of the new port being created by driver. */ > + new_attrs.port_index = > + nla_get_u32(info->attrs[DEVLINK_ATTR_PORT_INDEX]); > + new_attrs.port_index_valid = true; > + } > + if (info->attrs[DEVLINK_ATTR_PORT_CONTROLLER_NUMBER]) { > + new_attrs.controller = > + nla_get_u16(info->attrs[DEVLINK_ATTR_PORT_CONTROLLER_NUMBER]); > + new_attrs.controller_valid = true; > + } > + if (new_attrs.flavour == DEVLINK_PORT_FLAVOUR_PCI_SF && > + info->attrs[DEVLINK_ATTR_PORT_PCI_SF_NUMBER]) { > + new_attrs.sfnum = nla_get_u32(info->attrs[DEVLINK_ATTR_PORT_PCI_SF_NUMBER]); > + new_attrs.sfnum_valid = true; > + } > + > + err = devlink->ops->port_new(devlink, &new_attrs, extack, > + &new_port_index); > + if (err) > + return err; > + > + err = devlink_port_new_notifiy(devlink, new_port_index, info); > + if (err && err != -ENODEV) { > + /* Fail to send the response; destroy newly created port. */ > + devlink->ops->port_del(devlink, new_port_index, extack); > + } > + return err; > +} > + > +static int devlink_nl_cmd_port_del_doit(struct sk_buff *skb, > + struct genl_info *info) > +{ > + struct netlink_ext_ack *extack = info->extack; > + struct devlink *devlink = info->user_ptr[0]; > + unsigned int port_index; > + > + if (!devlink->ops->port_del) > + return -EOPNOTSUPP; > + > + if (!info->attrs[DEVLINK_ATTR_PORT_INDEX]) { > + NL_SET_ERR_MSG_MOD(extack, "Port index is not specified"); > + return -EINVAL; > + } > + port_index = nla_get_u32(info->attrs[DEVLINK_ATTR_PORT_INDEX]); > + > + return devlink->ops->port_del(devlink, port_index, extack); > +} > + > static int devlink_nl_sb_fill(struct sk_buff *msg, struct devlink *devlink, > struct devlink_sb *devlink_sb, > enum devlink_command cmd, u32 portid, > @@ -7605,6 +7710,10 @@ static const struct nla_policy devlink_nl_policy[DEVLINK_ATTR_MAX + 1] = { > [DEVLINK_ATTR_RELOAD_ACTION] = NLA_POLICY_RANGE(NLA_U8, DEVLINK_RELOAD_ACTION_DRIVER_REINIT, > DEVLINK_RELOAD_ACTION_MAX), > [DEVLINK_ATTR_RELOAD_LIMITS] = NLA_POLICY_BITFIELD32(DEVLINK_RELOAD_LIMITS_VALID_MASK), > + [DEVLINK_ATTR_PORT_FLAVOUR] = { .type = NLA_U16 }, > + [DEVLINK_ATTR_PORT_PCI_PF_NUMBER] = { .type = NLA_U16 }, > + [DEVLINK_ATTR_PORT_PCI_SF_NUMBER] = { .type = NLA_U32 }, > + [DEVLINK_ATTR_PORT_CONTROLLER_NUMBER] = { .type = NLA_U32 }, > }; > > static const struct genl_small_ops devlink_nl_ops[] = { > @@ -7644,6 +7753,18 @@ static const struct genl_small_ops devlink_nl_ops[] = { > .flags = GENL_ADMIN_PERM, > .internal_flags = DEVLINK_NL_FLAG_NO_LOCK, > }, > + { > + .cmd = DEVLINK_CMD_PORT_NEW, > + .doit = devlink_nl_cmd_port_new_doit, > + .flags = GENL_ADMIN_PERM, > + .internal_flags = DEVLINK_NL_FLAG_NO_LOCK, > + }, > + { > + .cmd = DEVLINK_CMD_PORT_DEL, > + .doit = devlink_nl_cmd_port_del_doit, > + .flags = GENL_ADMIN_PERM, > + .internal_flags = DEVLINK_NL_FLAG_NO_LOCK, > + }, > { > .cmd = DEVLINK_CMD_SB_GET, > .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP,
> From: Samudrala, Sridhar <sridhar.samudrala@intel.com> > Sent: Friday, January 22, 2021 2:21 AM > > > $ devlink port show > > pci/0000:06:00.0/65535: type eth netdev ens2f0np0 flavour physical > > port 0 splittable false > > > > $ devlink port add pci/0000:06:00.0 flavour pcisf pfnum 0 sfnum 88 > > Do we need to specify pfnum when adding a SF port? Isn't this redundant? > Isn't there a 1:1 mapping between the pci device and a pfnum? > No. it's not entirely redundant. Currently in most cases today it is same function number as that of PCI device. Netronome has one devlink instance that represents multiple PCI devices. Someday mlx5 driver might have it too for the single eswitch instance among multiple PCI devices of one physical card. So it is needed to specify.
> From: Samudrala, Sridhar <sridhar.samudrala@intel.com> > Sent: Friday, January 22, 2021 2:23 AM > > On 1/21/2021 12:52 AM, Saeed Mahameed wrote: > > From: Parav Pandit <parav@nvidia.com> > > > > devlink port function can be in active or inactive state. > > Allow users to get and set port function's state. > > > > When the port function it activated, its operational state may change > > after a while when the device is created and driver binds to it. > > Similarly on deactivation flow. > > > > To clearly describe the state of the port function and its device's > > operational state in the host system, define state and opstate > > attributes. > > > > Example of a PCI SF port which supports a port function: > > Create a device with ID=10 and one physical port. > Not clear what it means by creating a device with ID=10 and one physical > port? > I only see a SF with sfnum 88 in the following steps. > > That statement is no longer valid. Rest of the example covers the sfnum 88 related details and example. > > $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev > > > > $ devlink port show > > pci/0000:06:00.0/65535: type eth netdev ens2f0np0 flavour physical > > port 0 splittable false > > > > $ devlink port add pci/0000:06:00.0 flavour pcisf pfnum 0 sfnum 88 > > pci/0000:08:00.0/32768: type eth netdev eth6 flavour pcisf controller 0 > pfnum 0 sfnum 88 external false splittable false > > function: > > hw_addr 00:00:00:00:00:00 state inactive opstate detached > > > > $ devlink port show pci/0000:06:00.0/32768 > > pci/0000:06:00.0/32768: type eth netdev ens2f0npf0sf88 flavour pcisf > controller 0 pfnum 0 sfnum 88 external false splittable false > > function: > > hw_addr 00:00:00:00:88:88 state inactive opstate detached > > > > $ devlink port function set pci/0000:06:00.0/32768 hw_addr > > 00:00:00:00:88:88 state active > > > > $ devlink port show pci/0000:06:00.0/32768 -jp { > > "port": { > > "pci/0000:06:00.0/32768": { > > "type": "eth", > > "netdev": "ens2f0npf0sf88", > > "flavour": "pcisf", > > "controller": 0, > > "pfnum": 0, > > "sfnum": 88, > > "external": false, > > "splittable": false, > > "function": { > > "hw_addr": "00:00:00:00:88:88", > > "state": "active", > > "opstate": "attached" > > } > > } > > } > > } > > > > Signed-off-by: Parav Pandit <parav@nvidia.com> > > Reviewed-by: Jiri Pirko <jiri@nvidia.com> > > Reviewed-by: Vu Pham <vuhuong@nvidia.com> > > Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> > > --- > <snip>
On 1/21/2021 7:31 PM, Parav Pandit wrote: > > >> From: Samudrala, Sridhar <sridhar.samudrala@intel.com> >> Sent: Friday, January 22, 2021 2:21 AM >> >>> $ devlink port show >>> pci/0000:06:00.0/65535: type eth netdev ens2f0np0 flavour physical >>> port 0 splittable false >>> >>> $ devlink port add pci/0000:06:00.0 flavour pcisf pfnum 0 sfnum 88 >> >> Do we need to specify pfnum when adding a SF port? Isn't this redundant? >> Isn't there a 1:1 mapping between the pci device and a pfnum? >> > No. it's not entirely redundant. > Currently in most cases today it is same function number as that of PCI device. > Netronome has one devlink instance that represents multiple PCI devices. I am curious how this is done. I looked at doing this for ice but it became incredibly problematic because of interacting across multiple PCIe drivers.. Hmm. I'll have to go look at how this is handled in the netronome driver. Thanks, Jake
From: Saeed Mahameed <saeedm@nvidia.com> Hi Dave, Jakub, Jason, This series form Parav was the theme of this mlx5 release cycle, we've been waiting anxiously for the auxbus infrastructure to make it into the kernel, and now as the auxbus is in and all the stars are aligned, I can finally submit this patchset of the devlink and mlx5 subfunction support. For more detailed information about subfunctions please see detailed tag log below. Please pull and let me know if there's any problem. Thanks, Saeed. --- Changelog: v8->v9: - Use proper functions doc in patches #3,#4 v7->v8: - Address documentation related comments missed on v5, Jakub. v6-v7: - Resolve new kdoc warning v5->v6: - update docs and corrected spellings and typos according to previous review - use of shorted macro names - using updated callback to return port index - updated commit message example for add command return fields - driver name suffix corrected from 'mlx5_core' to 'sf' - using MLX5_ADEV_NAME prefix to match with other mlx5 auxiliary devices - fixed sf allocated condition - using 80 characters alignment - shorten the enum type names and enum values from PORT_FUNCTION to PORT_FN - return port attributes of newly created port - moved port add and delete callbacks pointer check before preparing attributes for driver - added comment to clarify that about desired port index during add callback - place SF number attribute only when port flavour is SF - packed the sf attribute structure - removed external flag for sf for initial patchset v4->v5: - Fix some typos in the documentation v3->v4: - Fix 32bit compilation issue v2->v3: - added header file sf/priv.h to cmd.c to avoid missing prototype warning - made mlx5_sf_table_disable as static function as its used only in one file v1->v2: - added documentation for subfunction and its mlx5 implementation - add MLX5_SF config option documentation - rebased - dropped devlink global lock improvement patch as mlx5 doesn't support reload while SFs are allocated - dropped devlink reload lock patch as mlx5 doesn't support reload when SFs are allocated - using updated vhca event from device to add remove auxiliary device - split sf devlink port allocation and sf hardware context allocation Thanks, Saeed. --- The following changes since commit 7b8fc0103bb51d1d3e1fb5fd67958612e709f883: bonding: add a vlan+srcmac tx hashing option (2021-01-19 19:30:32 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-updates-2021-01-13 for you to fetch changes up to 008536927ab1443b4ea2d40b8a9bb4e077903884: net/mlx5: Add devlink subfunction port documentation (2021-01-21 00:33:01 -0800) ---------------------------------------------------------------- mlx5 subfunction support Parav Pandit Says: ================= This patchset introduces support for mlx5 subfunction (SF). A subfunction is a lightweight function that has a parent PCI function on which it is deployed. mlx5 subfunction has its own function capabilities and its own resources. This means a subfunction has its own dedicated queues(txq, rxq, cq, eq). These queues are neither shared nor stolen from the parent PCI function. When subfunction is RDMA capable, it has its own QP1, GID table and rdma resources neither shared nor stolen from the parent PCI function. A subfunction has dedicated window in PCI BAR space that is not shared with the other subfunctions or parent PCI function. This ensures that all class devices of the subfunction accesses only assigned PCI BAR space. A Subfunction supports eswitch representation through which it supports tc offloads. User must configure eswitch to send/receive packets from/to subfunction port. Subfunctions share PCI level resources such as PCI MSI-X IRQs with their other subfunctions and/or with its parent PCI function. Patch summary: -------------- Patch 1 to 4 prepares devlink patch 5 to 7 mlx5 adds SF device support Patch 8 to 11 mlx5 adds SF devlink port support Patch 12 and 14 adds documentation Patch-1 prepares code to handle multiple port function attributes Patch-2 introduces devlink pcisf port flavour similar to pcipf and pcivf Patch-3 adds port add and delete driver callbacks Patch-4 adds port function state get and set callbacks Patch-5 mlx5 vhca event notifier support to distribute subfunction state change notification Patch-6 adds SF auxiliary device Patch-7 adds SF auxiliary driver Patch-8 prepares eswitch to handler SF vport Patch-9 adds eswitch helpers to add/remove SF vport Patch-10 implements devlink port add/del callbacks Patch-11 implements devlink port function get/set callbacks Patch-12 to 14 adds documentation Patch-12 added mlx5 port function documentation Patch-13 adds subfunction documentation Patch-14 adds mlx5 subfunction documentation Subfunction support is discussed in detail in RFC [1] and [2]. RFC [1] and extension [2] describes requirements, design and proposed plumbing using devlink, auxiliary bus and sysfs for systemd/udev support. Functionality of this patchset is best explained using real examples further below. overview: -------- A subfunction can be created and deleted by a user using devlink port add/delete interface. A subfunction can be configured using devlink port function attribute before its activated. When a subfunction is activated, it results in an auxiliary device on the host PCI device where it is deployed. A driver binds to the auxiliary device that further creates supported class devices. example subfunction usage sequence: ----------------------------------- Change device to switchdev mode: $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev Add a devlink port of subfunction flavour: $ devlink port add pci/0000:06:00.0 flavour pcisf pfnum 0 sfnum 88 Configure mac address of the port function: $ devlink port function set ens2f0npf0sf88 hw_addr 00:00:00:00:88:88 Now activate the function: $ devlink port function set ens2f0npf0sf88 state active Now use the auxiliary device and class devices: $ devlink dev show pci/0000:06:00.0 auxiliary/mlx5_core.sf.4 $ ip link show 127: ens2f0np0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 24:8a:07:b3:d1:12 brd ff:ff:ff:ff:ff:ff altname enp6s0f0np0 129: p0sf88: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:00:00:00:88:88 brd ff:ff:ff:ff:ff:ff $ rdma dev show 43: rdmap6s0f0: node_type ca fw 16.29.0550 node_guid 248a:0703:00b3:d112 sys_image_guid 248a:0703:00b3:d112 44: mlx5_0: node_type ca fw 16.29.0550 node_guid 0000:00ff:fe00:8888 sys_image_guid 248a:0703:00b3:d112 After use inactivate the function: $ devlink port function set ens2f0npf0sf88 state inactive Now delete the subfunction port: $ devlink port del ens2f0npf0sf88 [1] https://lore.kernel.org/netdev/20200519092258.GF4655@nanopsycho/ [2] https://marc.info/?l=linux-netdev&m=158555928517777&w=2 ================= ---------------------------------------------------------------- Parav Pandit (13): devlink: Prepare code to fill multiple port function attributes devlink: Introduce PCI SF port flavour and port attribute devlink: Support add and delete devlink port devlink: Support get and set state of port function net/mlx5: Introduce vhca state event notifier net/mlx5: SF, Add auxiliary device support net/mlx5: SF, Add auxiliary device driver net/mlx5: E-switch, Add eswitch helpers for SF vport net/mlx5: SF, Add port add delete functionality net/mlx5: SF, Port function state change support devlink: Add devlink port documentation devlink: Extend devlink port documentation for subfunctions net/mlx5: Add devlink subfunction port documentation Vu Pham (1): net/mlx5: E-switch, Prepare eswitch to handle SF vport Documentation/driver-api/auxiliary_bus.rst | 2 + .../device_drivers/ethernet/mellanox/mlx5.rst | 215 ++++++++ Documentation/networking/devlink/devlink-port.rst | 199 ++++++++ Documentation/networking/devlink/index.rst | 1 + drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 19 + drivers/net/ethernet/mellanox/mlx5/core/Makefile | 9 + drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 8 + drivers/net/ethernet/mellanox/mlx5/core/devlink.c | 19 + drivers/net/ethernet/mellanox/mlx5/core/eq.c | 5 +- .../mellanox/mlx5/core/esw/acl/egress_ofld.c | 2 +- .../ethernet/mellanox/mlx5/core/esw/devlink_port.c | 41 ++ drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 48 +- drivers/net/ethernet/mellanox/mlx5/core/eswitch.h | 78 +++ .../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 47 +- drivers/net/ethernet/mellanox/mlx5/core/events.c | 7 + drivers/net/ethernet/mellanox/mlx5/core/main.c | 60 ++- .../net/ethernet/mellanox/mlx5/core/mlx5_core.h | 12 + drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c | 20 + drivers/net/ethernet/mellanox/mlx5/core/sf/cmd.c | 49 ++ .../net/ethernet/mellanox/mlx5/core/sf/dev/dev.c | 275 ++++++++++ .../net/ethernet/mellanox/mlx5/core/sf/dev/dev.h | 55 ++ .../ethernet/mellanox/mlx5/core/sf/dev/driver.c | 101 ++++ .../net/ethernet/mellanox/mlx5/core/sf/devlink.c | 556 +++++++++++++++++++++ .../net/ethernet/mellanox/mlx5/core/sf/hw_table.c | 233 +++++++++ .../mellanox/mlx5/core/sf/mlx5_ifc_vhca_event.h | 82 +++ drivers/net/ethernet/mellanox/mlx5/core/sf/priv.h | 21 + drivers/net/ethernet/mellanox/mlx5/core/sf/sf.h | 100 ++++ .../ethernet/mellanox/mlx5/core/sf/vhca_event.c | 189 +++++++ .../ethernet/mellanox/mlx5/core/sf/vhca_event.h | 57 +++ drivers/net/ethernet/mellanox/mlx5/core/vport.c | 3 +- include/linux/mlx5/driver.h | 16 +- include/net/devlink.h | 100 ++++ include/uapi/linux/devlink.h | 25 + net/core/devlink.c | 310 ++++++++++-- 34 files changed, 2917 insertions(+), 47 deletions(-) create mode 100644 Documentation/networking/devlink/devlink-port.rst create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/sf/cmd.c create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/sf/dev/dev.c create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/sf/dev/dev.h create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/sf/dev/driver.c create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/sf/devlink.c create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/sf/hw_table.c create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/sf/mlx5_ifc_vhca_event.h create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/sf/priv.h create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/sf/sf.h create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/sf/vhca_event.c create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/sf/vhca_event.h