Re: [PATCH v29 01/20] net: Introduce direct data placement tcp offload

[Aurelien Aptel <aaptel@nvidia.com>]

Hannes Reinecke <hare@suse.de> writes:
> Hmm. One wonders: where is the different between this DDP implementation
> and the existing DDP implementation added with 4d288d5767f8 ("[SCSI]
> net: add FCoE offload support through net_device") ?

On first sight there are some similarities with the FCoE DDP offload but
things work differently.

Device querying:
- FCoE DDP has an operation for retrieving hardcoded attributes from the
  device (ndo_fcoe_get_hbainfo)
- ULP DDP has an operation for retrieving protocol generic and
  per-protocol info (limits())

Enablement:
- FCoE DDP has operations to enable/disable the feature on the device,
  and dedicated netdev feature bits
- ULP DPP uses netlink capability bits instead, as request by Jakub

Payload DDP:
- FCoE DDP works on a per-FCoE-frame basis, on top of ethernet. There
  are ddp_setup()/ddp_done() ops.
- ULP DPP works on a per-IO basis, on top of TCP. One IO can be split in
  multiple TCP packets. There are setup()/teardown() ops.

But because ULP DDP is per-IO and based on TCP, it requires knowledge
about the ULP header lenghts encoded in the HW/driver. It has to handle
OOO and dropped packets, via the resync() flow which FCoE lacks.

ULP DDP provides operation to enable/disable the offload per-socket,
which FCoE has no concept of.

Another difference is ULP DDP teardown operation is async. The ULP layer
does not have to wait for the HW to free up the resources: the ULP
provides callback to the driver, which the driver calls when it is done
tearing down so that the ULP can free its resources.

ULP DDP API also includes per-protocol stats retrieval. Overall, ULP DDP
was designed to be extended to support multiple protocols.

Thanks