All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wilczynski, Michal" <michal.wilczynski@intel.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: <netdev@vger.kernel.org>, <alexandr.lobakin@intel.com>,
	<jacob.e.keller@intel.com>, <jesse.brandeburg@intel.com>,
	<przemyslaw.kitszel@intel.com>, <anthony.l.nguyen@intel.com>,
	<kuba@kernel.org>, <ecree.xilinx@gmail.com>
Subject: Re: [PATCH net-next v8 3/9] devlink: Enable creation of the devlink-rate nodes from the driver
Date: Fri, 4 Nov 2022 15:34:35 +0100	[thread overview]
Message-ID: <5b9e1247-ce31-bb8a-b787-bb7b9a92f03e@intel.com> (raw)
In-Reply-To: <Y1+hLUPkXn3YWIlA@nanopsycho>



On 10/31/2022 11:19 AM, Jiri Pirko wrote:
> Fri, Oct 28, 2022 at 12:51:37PM CEST, michal.wilczynski@intel.com wrote:
>> Intel 100G card internal firmware hierarchy for Hierarchicial QoS is very
>> rigid and can't be easily removed. This requires an ability to export
>> default hierarchy to allow user to modify it. Currently the driver is
>> only able to create the 'leaf' nodes, which usually represent the vport.
>> This is not enough for HQoS implemented in Intel hardware.
>>
>> Introduce new function devl_rate_node_create() that allows for creation
>> of the devlink-rate nodes from the driver.
>>
>> Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com>
>> ---
>> include/net/devlink.h |  4 ++++
>> net/core/devlink.c    | 49 +++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 53 insertions(+)
>>
>> diff --git a/include/net/devlink.h b/include/net/devlink.h
>> index 929cb72ef412..9d0a424712fd 100644
>> --- a/include/net/devlink.h
>> +++ b/include/net/devlink.h
>> @@ -98,6 +98,8 @@ struct devlink_port_attrs {
>> 	};
>> };
>>
>> +#define DEVLINK_RATE_NAME_MAX_LEN 30
>> +
>> struct devlink_rate {
>> 	struct list_head list;
>> 	enum devlink_rate_type type;
>> @@ -1601,6 +1603,8 @@ void devlink_port_attrs_pci_sf_set(struct devlink_port *devlink_port,
>> 				   u32 controller, u16 pf, u32 sf,
>> 				   bool external);
>> int devl_rate_leaf_create(struct devlink_port *port, void *priv);
>> +int devl_rate_node_create(struct devlink *devlink, void *priv, char *node_name,
>> +			  char *parent_name);
>> void devl_rate_leaf_destroy(struct devlink_port *devlink_port);
>> void devl_rate_nodes_destroy(struct devlink *devlink);
>> void devlink_port_linecard_set(struct devlink_port *devlink_port,
>> diff --git a/net/core/devlink.c b/net/core/devlink.c
>> index b97c077cf66e..08f1bbd54c43 100644
>> --- a/net/core/devlink.c
>> +++ b/net/core/devlink.c
>> @@ -10270,6 +10270,55 @@ void devlink_port_attrs_pci_sf_set(struct devlink_port *devlink_port, u32 contro
>> }
>> EXPORT_SYMBOL_GPL(devlink_port_attrs_pci_sf_set);
>>
>> +/**
>> + * devl_rate_node_create - create devlink rate node
>> + * @devlink: devlink instance
>> + * @priv: driver private data
>> + * @node_name: name of the resulting node
>> + * @parent_name: name of the parent node
>> + *
>> + * Create devlink rate object of type node
>> + */
>> +int devl_rate_node_create(struct devlink *devlink, void *priv, char *node_name, char *parent_name)
> Nope, this is certainly incorrect. Do not refer to kernel object by
> string. You also don't have internal kernel api based on ifname to refer
> to struct net_device instance.
>
> Please have "struct devlink_rate *parent" to refer to parent node and
> make this function return "struct devlink_rate *".

Okay, I changed that and re-sent. The downside is I have to
store devlink_rate pointers in the driver instead of just names.

>
>
>> +{
>> +	struct devlink_rate *rate_node;
>> +	struct devlink_rate *parent;
>> +
>> +	rate_node = devlink_rate_node_get_by_name(devlink, node_name);
>> +	if (!IS_ERR(rate_node))
>> +		return -EEXIST;
>> +
>> +	rate_node = kzalloc(sizeof(*rate_node), GFP_KERNEL);
>> +	if (!rate_node)
>> +		return -ENOMEM;
>> +
>> +	if (parent_name) {
>> +		parent = devlink_rate_node_get_by_name(devlink, parent_name);
>> +		if (IS_ERR(parent)) {
>> +			kfree(rate_node);
>> +			return -ENODEV;
>> +		}
>> +		rate_node->parent = parent;
>> +		refcount_inc(&rate_node->parent->refcnt);
>> +	}
>> +
>> +	rate_node->type = DEVLINK_RATE_TYPE_NODE;
>> +	rate_node->devlink = devlink;
>> +	rate_node->priv = priv;
>> +
>> +	rate_node->name = kstrndup(node_name, DEVLINK_RATE_NAME_MAX_LEN, GFP_KERNEL);
> Why do you limit the name length? We don't limit the length passed from
> user, I see no reason to do it for driver.

I thought it's safer to limit this to avoid buffer overflow.
Changed this in v9.

>
>
>> +	if (!rate_node->name) {
>> +		kfree(rate_node);
>> +		return -ENOMEM;
>> +	}
>> +
>> +	refcount_set(&rate_node->refcnt, 1);
>> +	list_add(&rate_node->list, &devlink->rate_list);
>> +	devlink_rate_notify(rate_node, DEVLINK_CMD_RATE_NEW);
>> +	return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(devl_rate_node_create);
>> +
>> /**
>>   * devl_rate_leaf_create - create devlink rate leaf
>>   * @devlink_port: devlink port object to create rate object on
>> -- 
>> 2.37.2
>>


  reply	other threads:[~2022-11-04 14:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-28 10:51 [PATCH net-next v8 0/9] Implement devlink-rate API and extend it Michal Wilczynski
2022-10-28 10:51 ` [PATCH net-next v8 1/9] devlink: Introduce new parameter 'tx_priority' to devlink-rate Michal Wilczynski
2022-10-31 10:13   ` Jiri Pirko
2022-11-02 10:38     ` Wilczynski, Michal
2022-10-28 10:51 ` [PATCH net-next v8 2/9] devlink: Introduce new parameter 'tx_weight' " Michal Wilczynski
2022-10-28 10:51 ` [PATCH net-next v8 3/9] devlink: Enable creation of the devlink-rate nodes from the driver Michal Wilczynski
2022-10-31 10:19   ` Jiri Pirko
2022-11-04 14:34     ` Wilczynski, Michal [this message]
2022-10-28 10:51 ` [PATCH net-next v8 4/9] devlink: Allow for devlink-rate nodes parent reassignment Michal Wilczynski
2022-10-31 10:25   ` Jiri Pirko
2022-10-28 10:51 ` [PATCH net-next v8 5/9] devlink: Allow to set up parent in devl_rate_leaf_create() Michal Wilczynski
2022-10-31 10:26   ` Jiri Pirko
2022-10-28 10:51 ` [PATCH net-next v8 6/9] devlink: Allow to change priv in devlink-rate from parent_set callbacks Michal Wilczynski
2022-10-31 12:22   ` Jiri Pirko
2022-11-04 14:38     ` Wilczynski, Michal
2022-10-28 10:51 ` [PATCH net-next v8 7/9] ice: Introduce new parameters in ice_sched_node Michal Wilczynski
2022-10-28 10:51 ` [PATCH net-next v8 8/9] ice: Implement devlink-rate API Michal Wilczynski
2022-10-28 10:51 ` [PATCH net-next v8 9/9] ice: Prevent ADQ, DCB, RDMA coexistence with Custom Tx scheduler Michal Wilczynski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5b9e1247-ce31-bb8a-b787-bb7b9a92f03e@intel.com \
    --to=michal.wilczynski@intel.com \
    --cc=alexandr.lobakin@intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=ecree.xilinx@gmail.com \
    --cc=jacob.e.keller@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=przemyslaw.kitszel@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.