[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210212180639.GA511742@localhost>
Date: Fri, 12 Feb 2021 10:06:39 -0800
From: Chris Leech <cleech@...hat.com>
To: Shai Malin <smalin@...vell.com>
Cc: netdev@...r.kernel.org, linux-nvme@...ts.infradead.org,
sagi@...mberg.me, aelior@...vell.com, mkalderon@...vell.com,
nassa@...vell.com, malin1024@...il.com, Douglas.Farley@...l.com,
Erik.Smith@...l.com, kuba@...nel.org, pkushwaha@...vell.com,
davem@...emloft.net
Subject: Re: [RFC PATCH v3 00/11] NVMeTCP Offload ULP and QEDN Device Driver
On Sun, Feb 07, 2021 at 08:13:13PM +0200, Shai Malin wrote:
> Queue Initialization:
> =====================
> The nvme-tcp-offload ULP module shall register with the existing
> nvmf_transport_ops (.name = "tcp_offload"), nvme_ctrl_ops and blk_mq_ops.
> The nvme-tcp-offload vendor driver shall register to nvme-tcp-offload ULP
> with the following ops:
> - claim_dev() - in order to resolve the route to the target according to
> the net_dev.
> - create_queue() - in order to create offloaded nvme-tcp queue.
>
> The nvme-tcp-offload ULP module shall manage all the controller level
> functionalities, call claim_dev and based on the return values shall call
> the relevant module create_queue in order to create the admin queue and
> the IO queues.
Hi Shai,
How well does this claim_dev approach work with multipathing? Is it
expected that providing HOST_TRADDR is sufficient control over which
offload device will be used with multiple valid paths to the controller?
- Chris
Powered by blists - more mailing lists