Re: [tsvwg] RDMA Support by UDP FRAG Option

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 18 June 2021 09:36 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037A63A0A22 for <tsvwg@ietfa.amsl.com>; Fri, 18 Jun 2021 02:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eChYiAQd0XfS for <tsvwg@ietfa.amsl.com>; Fri, 18 Jun 2021 02:36:16 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id AC9F73A0A21 for <tsvwg@ietf.org>; Fri, 18 Jun 2021 02:36:16 -0700 (PDT)
Received: from GF-MBP-2.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id E877D1B0019B; Fri, 18 Jun 2021 10:36:07 +0100 (BST)
To: Tom Herbert <tom@herbertland.com>
Cc: Joseph Touch <touch@strayalpha.com>, TSVWG <tsvwg@ietf.org>
References: <CACL_3VEyLdQZ-3hvzXxyA8ehtWs2hXESZ2OqyAx+BeSg85+-cA@mail.gmail.com> <CACL_3VFE4TjKvmkfZjvNpWo6vVfKjz5w85=Q+yqnYZKcwbYLmQ@mail.gmail.com> <63FFC34B-2179-47F1-B325-21CAC3D1543A@strayalpha.com> <CACL_3VHTfxWaBj7TFEmBXBqovrrAj7XuFEZFUag_iBHr3Hx09g@mail.gmail.com> <0EBFC9B0-591A-4860-B327-6E617B83F4D1@strayalpha.com> <CALx6S34pT81TbfQDk2vKF8wBrXL312As79K=rEzUQ3Lmg7UvpA@mail.gmail.com> <7C51D926-9DBB-41F5-93B2-10F716F672B1@strayalpha.com> <CALx6S37uN8TsXQZ3cv5jmxwxSyBRjK=-GQ_MsWxPWSs21XoGHw@mail.gmail.com> <CACL_3VEx7+VnLz7OLdXyhZU41e+-oBz3dc8JdMV_7pLMfic6=w@mail.gmail.com> <fcc8762f-c042-7999-d2e4-f28384950a19@erg.abdn.ac.uk> <CALx6S36sWGcZmFpAhF4DfOMyf6Z0w5F9bemNfeM1yWV-r0M+BA@mail.gmail.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <8af3abf9-943f-13c1-e239-5efca27cf68c@erg.abdn.ac.uk>
Date: Fri, 18 Jun 2021 10:36:06 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <CALx6S36sWGcZmFpAhF4DfOMyf6Z0w5F9bemNfeM1yWV-r0M+BA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/KXhPfKlpdIyxUV1aJ35MIm5xz80>
Subject: Re: [tsvwg] RDMA Support by UDP FRAG Option
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jun 2021 09:36:21 -0000

On 17/06/2021 18:30, Tom Herbert wrote:
> On Thu, Jun 17, 2021 at 7:41 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>> I'd personally perfer the simpler formats - unless someone tells me that
>> coping with message buffers is made much easier by any more fiddlesome
>> (re)ordering of bytes.
>>
>> When teh dust has settled, I expect we should see an updated
>> fragmentation text.  I suspect we should consider the final format for
>> suitability for offload (perhaps Tom Herbert would look?) and for ease
>> of processing in message nbuffere (Tom Jones offered to look).
> Gorry,
>
> Please look at draft-herbert-udp-space-hdr-01 for my proposal as to
> how the UDP surplus space should be formatted. If there is interest, I
> could update draft to include considerations for UDP options
> fragmentation and reassembly offload as well as header/data split
> which is needed for zero-copy receive (i.e. packet headers are DMA'ed
> into one set of buffers to be processed by the stack, payload is
> DMA'ed to another set of buffers to be processed by the application).
>
> Tom

Thanks, I saw that a while ago, thanks for reminding people.

I think it would be good for the WG to focus on how to finish 
draft-ietf-tsvwg-udp-options, but I do seem some opportunities to use 
some of these ideas for making the fragment header - because that also 
places all data in the "option".

Gorry

>> Gorry
>>