On 11/5/2024 7:26 PM, Christoph Hellwig wrote:
> On Tue, Nov 05, 2024 at 06:34:29PM +0530, Anuj gupta wrote:
>> The field is used only at io_uring level, and it helps there in using the
>> SQE space flexibly.
>
> How so? There is absolutely no documentation for it in either the
> code or commit log. And if it is about sqe space management, meta_type
> is about the most confusing possible name as well. So someone please
> needs to write down how it is supposed to work and come up with a name
> that remotely makes sense for that.
Can add the documentation (if this version is palatable for Jens/Pavel),
but this was discussed in previous iteration:
1. Each meta type may have different space requirement in SQE.
Only for PI, we need so much space that we can't fit that in first SQE.
The SQE128 requirement is only for PI type.
Another different meta type may just fit into the first SQE. For that we
don't have to mandate SQE128.
2. If two meta types are known not to co-exist, they can be kept in the
same place within SQE. Since each meta-type is a flag, we can check what
combinations are valid within io_uring and throw the error in case of
incompatibility.
3. Previous version was relying on SQE128 flag. If user set the ring
that way, it is assumed that PI information was sent.
This is more explicitly conveyed now - if user passed META_TYPE_PI flag,
it has sent the PI. This comment in the code:
+ /* if sqe->meta_type is META_TYPE_PI, last 32 bytes are for PI */
+ union {
If this flag is not passed, parsing of second SQE is skipped, which is
the current behavior as now also one can send regular (non pi)
read/write on SQE128 ring.
