Messages in this thread | | | Date | Sat, 5 Mar 2022 15:09:15 +0800 | From | Mingbao Sun <> | Subject | Re: [PATCH 2/2] nvme-tcp: support specifying the congestion-control |
| |
On Fri, 4 Mar 2022 17:20:32 +0100 Christoph Hellwig <hch@lst.de> wrote:
> I'll let the NVMe/TCP maintainer comment on the actual functionality, > but: > > > + p = match_strdup(args); > > + if (!p) { > > + ret = -ENOMEM; > > + goto out; > > + } > > + > > + key = tcp_ca_get_key_by_name(NULL, p, > > &ecn_ca); > > + if (key == TCP_CA_UNSPEC) { > > + pr_err("congestion control %s not > > found.\n", > > + p); > > + ret = -EINVAL; > > + kfree(p); > > + goto out; > > + } > > We can't just call networking code from nvme-fabrics.ko
Well, actually I did have thought whether the calling of network API here is proper. Since I did find that there is no call to APIs of PCI/RDMA/TCP in fabrics.c.
But I hope the following could make a defense for it:
Anyway, we need to validate the tcp_congestion passed in from user-space, right? And it's reasonable to validate it via network API, right?
The role of nvmf_parse_options is similar to that of drivers/nvme/target/configfs.c from the target side. And both of them can not avoid handling specific options of the sub-classes (e.g., NVMF_OPT_HDR_DIGEST, NVMF_OPT_TOS, NVMF_OPT_KATO).
Given the fact that the configfs.c already contains some RDMA-specific code and has the calls to PCI-specific APIs pci_p2pdma_enable_store and pci_p2pdma_enable_show, so I added the calling of network APIs in configfs.c for the validation of tcp_congestion specified by the user.
So I feel this is also acceptable for nvme-fabrics.ko.
| |