Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Guixin Liu <kanie@linux.alibaba.com>
To: Chaitanya Kulkarni <chaitanyak@nvidia.com>
Cc: "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"hch@lst.de" <hch@lst.de>, "sagi@grimberg.me" <sagi@grimberg.me>
Subject: Re: [PATCH] nvmet: make nvmet_wq visible in sysfs
Date: Thu, 31 Oct 2024 10:01:25 +0800	[thread overview]
Message-ID: <ff0840eb-5b41-48df-9887-3539275761a1@linux.alibaba.com> (raw)
In-Reply-To: <1996168e-be7b-4811-91dd-c7782e955b30@nvidia.com>


在 2024/10/31 02:38, Chaitanya Kulkarni 写道:
> On 10/30/24 04:20, Guixin Liu wrote:
>> Sorry for the unclear explanation.
>>
>> The transport is tcp and the backend is block.
>>
>> This is just a solution level thing, in some complicated scenarios, we
>> deploy multiple
>>
>> missions on one machine(hybrid deployment), such as:
>>
>> 1. Dockers for function computation.
>>
>> 2. Real-time tasks.
>>
>> 3. Monitoring, and handling events and managemets.
>>
>> 4. And also nvme target server.
>>
>> All of them are retrict to their own cpu cores to prevent mutual
>> influence.
>>
>> There is no problem if nvmet_wq running on all cpus of course, but for
>> strict isolation,
>>
>> we need to do this retriction.
>>
>> I dont know if I've given enough detail.
>>
>> Best Regards,
>>
>> Guixin Liu
> can you please send a patch with detailed usecase ?
>
> Also, it will be nice (not a blocker to merge this patch) if you can
> provide
> steps similar to listed above so we can get this scenario tested, even
> better
> if you can submit a block test, but if not I'll send one once I get steps.
>
> -ck

I will send the v2 with our usecase to expain why we should restrict the 
cpumask,

I'm concerned whether blktests can handle such complex tests, as it 
relies on deploying

many Docker containers and services. Should it only test the case of 
setting the cpumask

with fio?

Best Regards,

Guixin Liu

>


  reply	other threads:[~2024-10-31  2:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-29  1:49 [PATCH] nvmet: make nvmet_wq visible in sysfs Guixin Liu
2024-10-29  5:04 ` Chaitanya Kulkarni
2024-10-29  6:46   ` Guixin Liu
2024-10-29 19:52     ` Chaitanya Kulkarni
2024-10-30  0:49       ` Chaitanya Kulkarni
2024-10-30  1:44       ` Guixin Liu
2024-10-30  5:53         ` hch
2024-10-30  6:44           ` Guixin Liu
2024-10-30  6:33         ` Chaitanya Kulkarni
2024-10-30 11:20           ` Guixin Liu
2024-10-30 18:38             ` Chaitanya Kulkarni
2024-10-31  2:01               ` Guixin Liu [this message]
2024-10-31  2:45                 ` Chaitanya Kulkarni
2024-10-31  6:39                   ` Chaitanya Kulkarni
2024-10-31  6:55                     ` Guixin Liu

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=ff0840eb-5b41-48df-9887-3539275761a1@linux.alibaba.com \
    --to=kanie@linux.alibaba.com \
    --cc=chaitanyak@nvidia.com \
    --cc=hch@lst.de \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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