netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Aurelien Aptel <aaptel@nvidia.com>
Cc: linux-nvme@lists.infradead.org, netdev@vger.kernel.org,
	sagi@grimberg.me, hch@lst.de, kbusch@kernel.org, axboe@fb.com,
	chaitanyak@nvidia.com, davem@davemloft.net,
	aurelien.aptel@gmail.com, smalin@nvidia.com, malin1024@gmail.com,
	ogerlitz@nvidia.com, yorayz@nvidia.com, borisp@nvidia.com,
	galshalom@nvidia.com, mgurtovoy@nvidia.com
Subject: Re: [PATCH v14 02/20] netlink: add new family to manage ULP_DDP enablement and stats
Date: Fri, 8 Sep 2023 14:49:09 -0700	[thread overview]
Message-ID: <20230908144909.5d7a36ce@kernel.org> (raw)
In-Reply-To: <20230906113018.2856-3-aaptel@nvidia.com>

On Wed,  6 Sep 2023 11:30:00 +0000 Aurelien Aptel wrote:
> Add a new netlink family to get/set ULP DDP capabilities on a network
> device and to retrieve statistics.
> 
> The messages use the genetlink infrastructure and are specified in a
> YAML file which was used to generate some of the files in this commit:
> 
> ./tools/net/ynl/ynl-gen-c.py --mode kernel \
>     --spec ./Documentation/netlink/specs/ulp_ddp.yaml --header \
>     -o net/core/ulp_ddp_gen_nl.h
> ./tools/net/ynl/ynl-gen-c.py --mode kernel \
>     --spec ./Documentation/netlink/specs/ulp_ddp.yaml --source \
>     -o net/core/ulp_ddp_gen_nl.c
> ./tools/net/ynl/ynl-gen-c.py --mode uapi \
>     --spec ./Documentation/netlink/specs/ulp_ddp.yaml --header \
>     > include/uapi/linux/ulp_ddp_nl.h  

Looks mostly good, but we lost dump support. TAL at netdev_nl_dev_get_dumpit(), 
the iteration is not that hard, I reckon we should support dumps.

Few extra nits below.

> +static struct ulp_ddp_netdev_caps *netdev_ulp_ddp_caps(struct net_device *dev)
> +{
> +#ifdef CONFIG_ULP_DDP
> +	return &dev->ulp_ddp_caps;
> +#else
> +	return NULL;
> +#endif

Are the ifdefs still needed? Can't we compile out all of the family code
if the config is not selected?

> +/* pre_doit */
> +int ulp_ddp_get_netdev(const struct genl_split_ops *ops,
> +		       struct sk_buff *skb, struct genl_info *info)
> +{
> +	struct reply_data *data;
> +
> +	if (GENL_REQ_ATTR_CHECK(info, ULP_DDP_A_DEV_IFINDEX))
> +		return -EINVAL;
> +
> +	data = kzalloc(sizeof(*data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	data->ifindex = nla_get_u32(info->attrs[ULP_DDP_A_DEV_IFINDEX]);
> +	data->dev = netdev_get_by_index(genl_info_net(info),
> +					data->ifindex,
> +					&data->tracker,
> +					GFP_KERNEL);
> +

nit pointless empty line.

> +	if (!data->dev) {
> +		kfree(data);
> +		return -EINVAL;

ENOENT ? Maybe also 

		NL_SET_BAD_ATTR(info->extack, info->attrs[ULP_DDP_A_DEV_IFINDEX]) 
?

> +int ulp_ddp_nl_set_doit(struct sk_buff *skb, struct genl_info *info)
> +{
> +	struct reply_data *data = info->user_ptr[0];
> +	unsigned long wanted, wanted_mask;
> +	struct sk_buff *rsp;
> +	bool notify;
> +	int ret;
> +
> +	if (GENL_REQ_ATTR_CHECK(info, ULP_DDP_A_DEV_WANTED) ||
> +	    GENL_REQ_ATTR_CHECK(info, ULP_DDP_A_DEV_WANTED_MASK))
> +		return -EINVAL;
> +
> +	rsp = genlmsg_new(reply_size(ULP_DDP_CMD_STATS), GFP_KERNEL);
> +	if (!rsp)
> +		return -EMSGSIZE;
> +
> +	wanted = nla_get_u64(info->attrs[ULP_DDP_A_DEV_WANTED]);
> +	wanted_mask = nla_get_u64(info->attrs[ULP_DDP_A_DEV_WANTED_MASK]);
> +
> +	ret = apply_bits(data, &wanted, &wanted_mask, info->extack);
> +	if (ret < 0)
> +		return ret;

leaks rsp

> +	notify = !!ret;
> +	ret = prepare_data(info, data, ULP_DDP_CMD_SET);
> +	if (ret)
> +		return ret;
> +
> +	ret = fill_data(rsp, data, ULP_DDP_CMD_SET, info->snd_portid, info->snd_seq, 0);

fill_date() can probably use genlmsg_iput() ?
-- 
pw-bot: cr

  reply	other threads:[~2023-09-08 21:49 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-06 11:29 [PATCH v14 00/20] nvme-tcp receive offloads Aurelien Aptel
2023-09-06 11:29 ` [PATCH v14 01/20] net: Introduce direct data placement tcp offload Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 02/20] netlink: add new family to manage ULP_DDP enablement and stats Aurelien Aptel
2023-09-08 21:49   ` Jakub Kicinski [this message]
2023-09-11 13:59     ` Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 03/20] iov_iter: skip copy if src == dst for direct data placement Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 04/20] net/tls,core: export get_netdev_for_sock Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 05/20] nvme-tcp: Add DDP offload control path Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 06/20] nvme-tcp: Add DDP data-path Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 07/20] nvme-tcp: RX DDGST offload Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 08/20] nvme-tcp: Deal with netdevice DOWN events Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 09/20] Documentation: add ULP DDP offload documentation Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 10/20] net/mlx5e: Rename from tls to transport static params Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 11/20] net/mlx5e: Refactor ico sq polling to get budget Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 12/20] net/mlx5: Add NVMEoTCP caps, HW bits, 128B CQE and enumerations Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 13/20] net/mlx5e: NVMEoTCP, offload initialization Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 14/20] net/mlx5e: TCP flow steering for nvme-tcp acceleration Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 15/20] net/mlx5e: NVMEoTCP, use KLM UMRs for buffer registration Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 16/20] net/mlx5e: NVMEoTCP, queue init/teardown Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 17/20] net/mlx5e: NVMEoTCP, ddp setup and resync Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 18/20] net/mlx5e: NVMEoTCP, async ddp invalidation Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 19/20] net/mlx5e: NVMEoTCP, data-path for DDP+DDGST offload Aurelien Aptel
2023-09-06 11:30 ` [PATCH v14 20/20] net/mlx5e: NVMEoTCP, statistics Aurelien Aptel

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=20230908144909.5d7a36ce@kernel.org \
    --to=kuba@kernel.org \
    --cc=aaptel@nvidia.com \
    --cc=aurelien.aptel@gmail.com \
    --cc=axboe@fb.com \
    --cc=borisp@nvidia.com \
    --cc=chaitanyak@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=galshalom@nvidia.com \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=malin1024@gmail.com \
    --cc=mgurtovoy@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=ogerlitz@nvidia.com \
    --cc=sagi@grimberg.me \
    --cc=smalin@nvidia.com \
    --cc=yorayz@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).