Extending the functionality of some SQE OPs

Extending the functionality of some SQE OPs

[Mark Papadakis]

Would it make sense to extend the semantics of some OPS of specific syscalls to, for example, return in the CQE more than just an int (matching the semantics of the specific syscall they represent)?
For example, the respective OP for accept/accept4 returns an int for error or the fd of the accepted connection’s socket FD. But, given the clean-room implementation of io_uring, this may be a good opportunity to expand on it. Maybe there should be another field in the CQEs e.g
union {
	int i32;
	uint64_t u64;
	// whatever makes sense
} ret_ex;
Where the implementation of some OPs would access and set accordingly. For example, the OP for accept could set ret_ex.i32 to 1 if there are more outstanding FDs to be dequeued from the accepted connections queue, so that the application should accept again thereby draining it - as opposed to being woken up multiple times to do so. Other OPs may take advantage of this for other reasons.

Maybe it doesn’t make as much sense as I think it does, but if anything, it could become very useful down the road, once more syscalls(even OPs that are entirely new are not otherwise represent existing syscalls?) are implemented(invented?). 

@markpapadakis

Re: Extending the functionality of some SQE OPs

[Jens Axboe]

On 1/21/20 12:50 AM, Mark Papadakis wrote:
> Would it make sense to extend the semantics of some OPS of specific
> syscalls to, for example, return in the CQE more than just an int
> (matching the semantics of the specific syscall they represent)?  For
> example, the respective OP for accept/accept4 returns an int for error
> or the fd of the accepted connection’s socket FD. But, given the
> clean-room implementation of io_uring, this may be a good opportunity
> to expand on it. Maybe there should be another field in the CQEs e.g
>
> union {
> 	int i32;
> 	uint64_t u64;
> 	// whatever makes sense
> } ret_ex;
>
> Where the implementation of some OPs would access and set accordingly.
> For example, the OP for accept could set ret_ex.i32 to 1 if there are
> more outstanding FDs to be dequeued from the accepted connections
> queue, so that the application should accept again thereby draining it
> - as opposed to being woken up multiple times to do so. Other OPs may
> take advantage of this for other reasons.
> 
> Maybe it doesn’t make as much sense as I think it does, but if
> anything, it could become very useful down the road, once more
> syscalls(even OPs that are entirely new are not otherwise represent
> existing syscalls?) are implemented(invented?). 

Would certainly be possible, I'd suggest using a union around cqe->flags
for that. The flags are unused as-of now, so we could introduce a way to
know if we're passing back flags or u32 worth of data instead. If we
unionize res2 with flags and reserve the upper bit of flags to say
"flags are valid" or something like that, then we get 31 bits of int
that could be used to pass back extra information.

-- 
Jens Axboe

Re: Extending the functionality of some SQE OPs

[Mark Papadakis]

This sounds great. It may wind up being far more useful or important down the road, and if this doesn’t bloat the CQE, that’s fantastic. 

Thanks,
@markpapadakis

> On 21 Jan 2020, at 9:55 PM, Jens Axboe <axboe@kernel.dk> wrote:
> 
> On 1/21/20 12:50 AM, Mark Papadakis wrote:
>> Would it make sense to extend the semantics of some OPS of specific
>> syscalls to, for example, return in the CQE more than just an int
>> (matching the semantics of the specific syscall they represent)?  For
>> example, the respective OP for accept/accept4 returns an int for error
>> or the fd of the accepted connection’s socket FD. But, given the
>> clean-room implementation of io_uring, this may be a good opportunity
>> to expand on it. Maybe there should be another field in the CQEs e.g
>> 
>> union {
>>    int i32;
>>    uint64_t u64;
>>    // whatever makes sense
>> } ret_ex;
>> 
>> Where the implementation of some OPs would access and set accordingly.
>> For example, the OP for accept could set ret_ex.i32 to 1 if there are
>> more outstanding FDs to be dequeued from the accepted connections
>> queue, so that the application should accept again thereby draining it
>> - as opposed to being woken up multiple times to do so. Other OPs may
>> take advantage of this for other reasons.
>> 
>> Maybe it doesn’t make as much sense as I think it does, but if
>> anything, it could become very useful down the road, once more
>> syscalls(even OPs that are entirely new are not otherwise represent
>> existing syscalls?) are implemented(invented?). 
> 
> Would certainly be possible, I'd suggest using a union around cqe->flags
> for that. The flags are unused as-of now, so we could introduce a way to
> know if we're passing back flags or u32 worth of data instead. If we
> unionize res2 with flags and reserve the upper bit of flags to say
> "flags are valid" or something like that, then we get 31 bits of int
> that could be used to pass back extra information.
> 
> -- 
> Jens Axboe
> 

Re: Extending the functionality of some SQE OPs

[Jens Axboe]

On 1/21/20 1:54 PM, Mark Papadakis wrote:
> 
> 
> This sounds great. It may wind up being far more useful or important
> down the road, and if this doesn’t bloat the CQE, that’s fantastic. 

It's there if we want to use it. And we cannot bloat the CQE otherwise,
the size is fixed. But we can use those 32-bits that are currently not
used.

-- 
Jens Axboe