FR: define nvme-mi log truncate size in header

[drakedog2008]

Hi @jk-ozlabs ,

Can we define the size in header file. So the client doesn't need to define their own and conflict in case of future change.

https://github.com/linux-nvme/libnvme/blob/master/src/nvme/mi.c#L502

[jk-ozlabs]

This should be transparent to the client; it's just the size that is transferred in each chunk. Is there a need to know this chunk size outside of the library?

[drakedog2008]

Given all nvme calls are blocking for libnvme(mi), the client need to schedule the tasks itself.

One scenario is that the we need the thermal info for at most 1 second delay for pid loop. The log will be definitely large to block so truncate will be done by client. It is good (but not necessary) to know the payload size of the lib implementation so the client could better optimize the performance.

[jk-ozlabs]

A couple of comments/questions:

One scenario is that the we need the thermal info for at most 1 second delay for pid loop

OK, that's reasonable

The log will be definitely large to block so truncate will be done by client

Not sure I understand this by "client", do you mean the caller of the libnvme API?

In this case, wouldn't it be much better for the truncate to be done by libnvme instead? Otherwise we're transferring data from the drive, but then throwing part of that away. If there's a specific range of bytes in the Log Page that you need for this regular data, we can request just that range - that way, we can minimise the amount of data going over the (relatively slow) i2c bus.

This may need a new function to get a partial chunk of log page data - like we have for identify already. I can add that if you like.

But on to this feature request: the chunk size is really an implementation detail of libnvme - if we can avoid exposing it, I would prefer that.

[drakedog2008]

Not sure I understand this by "client", do you mean the caller of the libnvme API?

Yes.

In this case, wouldn't it be much better for the truncate to be done by libnvme instead? Otherwise we're transferring data from the drive, but then throwing part of that away. If there's a specific range of bytes in the Log Page that you need for this regular data, we can request just that range - that way, we can minimise the amount of data going over the (relatively slow) i2c bus.

Given the libnvme is synchronous api, the internal truncate within the libnvme won't unblock the caller. So for the high priorities with concurrent task scenario , the client has to truncate the transfer by itself to do scheduling and context(task) switch. The internal chuck size may be a reasonable parameter for the client to determine the client side trunc size.

This may need a new function to get a partial chunk of log page data - like we have for identify already. I can add that if you like.

yes. offset is required for all large data transfer CMD, log page is especially the case.

[igaw]

Good to close? Or is there anything in the works?

[jk-ozlabs]

There's still an item to add a partial log page transfer. @drakedog2008 , I'm assuming using the lpo-based chunking isn't suitable for this case?

If so, I can rename this PR to something more suitable.