From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH 05/15] Add io_uring IO interface
Date: Fri, 11 Jan 2019 11:34:40 -0700
Message-ID: <f97a5b9f-68f3-c4af-649d-7dffbc35e37f@kernel.dk>
References: <20190110024404.25372-1-axboe@kernel.dk>
 <20190110024404.25372-6-axboe@kernel.dk> <yq1sgxzys3s.fsf@oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: linux-fsdevel@vger.kernel.org, linux-aio@kvack.org,
 linux-block@vger.kernel.org, linux-arch@vger.kernel.org, hch@lst.de,
 jmoyer@redhat.com, avi@scylladb.com
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Return-path: <owner-linux-aio@kvack.org>
In-Reply-To: <yq1sgxzys3s.fsf@oracle.com>
Content-Language: en-US
Sender: owner-linux-aio@kvack.org
List-Id: linux-fsdevel.vger.kernel.org

On 1/11/19 11:19 AM, Martin K. Petersen wrote:
> 
> Jens,
> 
>> +struct io_uring_sqe {
>> +	__u8	opcode;
>> +	__u8	flags;
>> +	__u16	ioprio;
>> +	__s32	fd;
>> +	__u64	off;
>> +	union {
>> +		void	*addr;
>> +		__u64	__pad;
>> +	};
>> +	__u32	len;
>> +	union {
>> +		__kernel_rwf_t	rw_flags;
>> +		__u32		__resv;
>> +	};
>> +};
> 
> A bit tongue in cheek and yet somewhat serious: While I'm super excited
> about the 4 x 64 bitness of the sqe, where does the integrity buffer go?
> Or the 128-bit KV store key. How do we extend this interface beyond the
> flags?

For integrity buffers, how about we stash them on the side? The newer
series has an extra system call, io_uring_register(), which is currently
used for registering files and buffers for IO on the side. You could
trivially tie an integrity buffer to an sqe through that.

For KV, I thint that's an actually interesting use case (sorry,
integrity), and we might just want to bite the bullet and extend the sqe
to full 64 bytes.  We're currently at 48 bytes, which leaves us with 16
bytes of space for KV, and other use cases.

-- 
Jens Axboe

--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org.  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=ba4g=PT=vger.kernel.org=linux-fsdevel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS
	autolearn=unavailable autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 0C71DC43444
	for <linux-fsdevel@archiver.kernel.org>; Fri, 11 Jan 2019 18:34:47 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by mail.kernel.org (Postfix) with ESMTP id D542F2183F
	for <linux-fsdevel@archiver.kernel.org>; Fri, 11 Jan 2019 18:34:46 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel-dk.20150623.gappssmtp.com header.i=@kernel-dk.20150623.gappssmtp.com header.b="YaRRhW4r"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1732322AbfAKSep (ORCPT
        <rfc822;linux-fsdevel@archiver.kernel.org>);
        Fri, 11 Jan 2019 13:34:45 -0500
Received: from mail-pf1-f194.google.com ([209.85.210.194]:41400 "EHLO
        mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1729884AbfAKSep (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Fri, 11 Jan 2019 13:34:45 -0500
Received: by mail-pf1-f194.google.com with SMTP id b7so7331012pfi.8
        for <linux-fsdevel@vger.kernel.org>; Fri, 11 Jan 2019 10:34:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=kernel-dk.20150623.gappssmtp.com; s=20150623;
        h=subject:to:cc:references:from:message-id:date:user-agent
         :mime-version:in-reply-to:content-language:content-transfer-encoding;
        bh=lszYkSIu7S0G0GkbSWA6G+IUU99PAcTok/8iYuS+0Ig=;
        b=YaRRhW4r0sXDl899rnnW0bmtsUu+0KKxCP0jj2tRzDrR0dusN6rJEBnDBw4WhY28Ph
         deJyTcNTtTuSVoPZbVLfyFyftncmg5WG/TGIfCwSy/WnR/w4qFbhv5ABKq0HKrpDykud
         LncFXcN00wus7FWpzGxANj1xB+GiTiAWNtikIP6kBLUxXpanH/2DtKG1U+r6znZQlIV2
         yhyvAzSfoGrvMMPXWSKeyhB21q9S0VZcPCvUqavsvvJDbaSOAH+nIH14ZZvcKFKExxmw
         jOc/Tz3KllhN3w8diLSnCnyI2OkizfiNFFbAl3UoxSEag8mUZnBmOpFN8NQ0NyS2fU24
         M0Sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:subject:to:cc:references:from:message-id:date
         :user-agent:mime-version:in-reply-to:content-language
         :content-transfer-encoding;
        bh=lszYkSIu7S0G0GkbSWA6G+IUU99PAcTok/8iYuS+0Ig=;
        b=hpz26aM2YJvkoQ3x48uQWkHdx3CrD+Vk0NhntD7tG9oaiwqfcDVT3sJtvhdF4cVnvZ
         qcPyezIriYAJ29fZgTFDJiTjYMi9pSn15+tnC0hagBeNEhfz0/MUFl6AfJqfMudqLliQ
         giw/0yy1n1o3EcrNi1rM4YsfT3OkAghP/pBabW8jf4Xmzq9An0hCpBBtMLtxz06Xj+Yl
         ePd2rmYnq/DQhOgflr2WJcKyF9DNoC6v7dJ87mQ6E5J0R11auBFQDR90SJO1pXMtCDIK
         3/4uioANF9azexeo1KdwN4H5HtChzPQxp1z8R4iCUMmBHaEymQ6DxpsreiDVXOCROYM0
         1W9A==
X-Gm-Message-State: AJcUukdek+M0hm9emzlSp+JGVfZOUCKxFFq8QkqTFm76rE9U+bjpIlGa
        SPvQhBwZOZTwbCpgvtp+rlwNJg==
X-Google-Smtp-Source: ALg8bN6xID5YBAtKrZY68YrPvVJLAiahon10dfUNpDL3hYzG5nv9ljX9bXqwuVpp0uDT7xWsDYs+Eg==
X-Received: by 2002:a63:2c82:: with SMTP id s124mr14048409pgs.73.1547231684220;
        Fri, 11 Jan 2019 10:34:44 -0800 (PST)
Received: from ?IPv6:2620:10d:c081:1131::1250? ([2620:10d:c090:180::1:fab8])
        by smtp.gmail.com with ESMTPSA id k191sm92447325pgd.9.2019.01.11.10.34.41
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 11 Jan 2019 10:34:42 -0800 (PST)
Subject: Re: [PATCH 05/15] Add io_uring IO interface
To:     "Martin K. Petersen" <martin.petersen@oracle.com>
Cc:     linux-fsdevel@vger.kernel.org, linux-aio@kvack.org,
        linux-block@vger.kernel.org, linux-arch@vger.kernel.org,
        hch@lst.de, jmoyer@redhat.com, avi@scylladb.com
References: <20190110024404.25372-1-axboe@kernel.dk>
 <20190110024404.25372-6-axboe@kernel.dk> <yq1sgxzys3s.fsf@oracle.com>
From:   Jens Axboe <axboe@kernel.dk>
Message-ID: <f97a5b9f-68f3-c4af-649d-7dffbc35e37f@kernel.dk>
Date:   Fri, 11 Jan 2019 11:34:40 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <yq1sgxzys3s.fsf@oracle.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-fsdevel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-fsdevel.vger.kernel.org>
X-Mailing-List: linux-fsdevel@vger.kernel.org
Message-ID: <20190111183440.U6r93ddYp4iBHLnhNkNuX1CPjzn2Afqnhp-ii0eOiws@z>

On 1/11/19 11:19 AM, Martin K. Petersen wrote:
> 
> Jens,
> 
>> +struct io_uring_sqe {
>> +	__u8	opcode;
>> +	__u8	flags;
>> +	__u16	ioprio;
>> +	__s32	fd;
>> +	__u64	off;
>> +	union {
>> +		void	*addr;
>> +		__u64	__pad;
>> +	};
>> +	__u32	len;
>> +	union {
>> +		__kernel_rwf_t	rw_flags;
>> +		__u32		__resv;
>> +	};
>> +};
> 
> A bit tongue in cheek and yet somewhat serious: While I'm super excited
> about the 4 x 64 bitness of the sqe, where does the integrity buffer go?
> Or the 128-bit KV store key. How do we extend this interface beyond the
> flags?

For integrity buffers, how about we stash them on the side? The newer
series has an extra system call, io_uring_register(), which is currently
used for registering files and buffers for IO on the side. You could
trivially tie an integrity buffer to an sqe through that.

For KV, I thint that's an actually interesting use case (sorry,
integrity), and we might just want to bite the bullet and extend the sqe
to full 64 bytes.  We're currently at 48 bytes, which leaves us with 16
bytes of space for KV, and other use cases.

-- 
Jens Axboe