[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <67a9e53e-4ac9-7ba8-9713-96c1dfe1e341@nvidia.com>
Date: Thu, 27 Apr 2023 23:12:13 +0000
From: Chaitanya Kulkarni <chaitanyak@...dia.com>
To: Christophe JAILLET <christophe.jaillet@...adoo.fr>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Chaitanya Kulkarni <chaitanyak@...dia.com>,
Sagi Grimberg <sagi@...mberg.me>,
"kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>,
Christoph Hellwig <hch@....de>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
"kbusch@...nel.org" <kbusch@...nel.org>
Subject: Re: [PATCH] nvmet: Reorder fields in 'struct nvmet_ns'
(+Keith, for host side)
> ---
> More aggressive grouping could be done to be more future proof, but the
> way the struct nvmet_ns is written suggest that some fields should be
> kept together. So keep grouping as-is.
>
>
you can send RFC and I'll be happy to take a look if it's going
have any benefit, it will take some time though..
for host side :-
while you are at it, it might be useful to take a look at the structures
that are accessed in the fast path on the host side ?
unless there is some reason for not doing that ...
-ck
Powered by blists - more mailing lists