On Wed, Feb 3, 2021 at 10:54 AM Sagi Grimberg wrote:
> > +static
> > +int nvme_tcp_teardown_ddp(struct nvme_tcp_queue *queue,
> > + u16 command_id,
> > + struct request *rq)
> > +{
> > + struct nvme_tcp_request *req = blk_mq_rq_to_pdu(rq);
> > +
Given how much ddp code there is can you split it into a separate file?
mmm, do we need to check the preferences or get to a consensus among
the maintainers for that one?
Not sure if moving it would be better here. Given that the ddp code is
working directly on nvme-tcp structs we'll need a
On Wed, Feb 03, 2021 at 12:56:35AM -0800, Sagi Grimberg wrote:
>
>>> Given how much ddp code there is can you split it into a separate file?
>>
>> mmm, do we need to check the preferences or get to a consensus among
>> the maintainers for that one?
>
> Not sure if moving it would be better here. Gi
Given how much ddp code there is can you split it into a separate file?
mmm, do we need to check the preferences or get to a consensus among
the maintainers for that one?
Not sure if moving it would be better here. Given that the ddp code is
working directly on nvme-tcp structs we'll need a
On 2/1/21 2:04 AM, Boris Pismenny wrote:
Introduce the NVMe-TCP DDP data-path offload.
Using this interface, the NIC hardware will scatter TCP payload directly
to the BIO pages according to the command_id in the PDU.
To maintain the correctness of the network stack, the driver is expected
to c
On Mon, Feb 1, 2021 at 7:40 PM Christoph Hellwig wrote:
> Given how much ddp code there is can you split it into a separate file?
mmm, do we need to check the preferences or get to a consensus among
the maintainers for that one?
Given how much ddp code there is can you split it into a separate file?
Introduce the NVMe-TCP DDP data-path offload.
Using this interface, the NIC hardware will scatter TCP payload directly
to the BIO pages according to the command_id in the PDU.
To maintain the correctness of the network stack, the driver is expected
to construct SKBs that point to the BIO pages.
Th