Re: Extending the functionality of some SQE OPs

[Mark Papadakis <markuspapadakis@icloud.com>]

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
>