From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 231A3EB64DA for ; Thu, 22 Jun 2023 22:54:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60E148D0002; Thu, 22 Jun 2023 18:54:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BE268D0001; Thu, 22 Jun 2023 18:54:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 485DF8D0002; Thu, 22 Jun 2023 18:54:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 39CEE8D0001 for ; Thu, 22 Jun 2023 18:54:44 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A4A9AA094F for ; Thu, 22 Jun 2023 22:54:43 +0000 (UTC) X-FDA: 80931890046.21.2713CFC Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf03.hostedemail.com (Postfix) with ESMTP id 967012001C for ; Thu, 22 Jun 2023 22:54:41 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AznrrQAb; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf03.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687474481; a=rsa-sha256; cv=none; b=TeCWwrDJX5srauy/kow6FMoNXL0EySq0Juu89qS1yXaHhvAdhk9P8p/XhN4cjn8iZOh4uD LtndDEy4VaofbXPP9TTrkMESMHyLtdGu4xag4ipiG9dZS/oc+41k9qZebysSf1plKd53H4 ZERMvmmGlFT6E3crrtidwMVQdxySHpE= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AznrrQAb; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf03.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687474481; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CoZIUtTkYvBb1iCo4vdxE0rm6LAMYX4km4nzgk6efLk=; b=JrHc/C9b60snUlSGZNQya8+AOyYImfU/kYp05F/1yZ0xAKbRFbX306NYwzD8+mCwXKDGHP VllPYcgVxnDSOnWBV3JV0B+7k2e/dylXNToLZWJCsWw+HR6/O5DOE2Lom9OU4zeu7Fl+HK VroBXgLftVq+BwmAKs26R+N3T5KUcZ8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687474480; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CoZIUtTkYvBb1iCo4vdxE0rm6LAMYX4km4nzgk6efLk=; b=AznrrQAbH3/uAvDllGFtQ+mPPqywsWhyJt2B953efaOPJBO41YAH3vytdpPwN6lopqJQjH goB2wZ8+pkzuAVvFwNeJunlRgGr4hZDDdEpJwQq22LhD0ZKpQdOwJ0KR5BR0xovVLEH3bV WXI9iyvgFgSoEeNbtbwjQhhgl2SYOcU= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-651-jZIMhQ75NBCZnOxUMJ0HiA-1; Thu, 22 Jun 2023 18:54:34 -0400 X-MC-Unique: jZIMhQ75NBCZnOxUMJ0HiA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B49101C05EBA; Thu, 22 Jun 2023 22:54:33 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.42.28.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 14100C1ED97; Thu, 22 Jun 2023 22:54:31 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <20230622132835.3c4e38ea@kernel.org> References: <20230622132835.3c4e38ea@kernel.org> <20230622111234.23aadd87@kernel.org> <20230620145338.1300897-1-dhowells@redhat.com> <20230620145338.1300897-2-dhowells@redhat.com> <1952674.1687462843@warthog.procyon.org.uk> To: Jakub Kicinski Cc: dhowells@redhat.com, Eric Dumazet , netdev@vger.kernel.org, Alexander Duyck , "David S. Miller" , Paolo Abeni , Willem de Bruijn , David Ahern , Matthew Wilcox , Jens Axboe , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Menglong Dong Subject: Re: [PATCH net-next v3 01/18] net: Copy slab data for sendmsg(MSG_SPLICE_PAGES) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1958076.1687474471.1@warthog.procyon.org.uk> Date: Thu, 22 Jun 2023 23:54:31 +0100 Message-ID: <1958077.1687474471@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 967012001C X-Stat-Signature: mdnxdjd1jzgpgu7n1xepwdacuyfumzqy X-HE-Tag: 1687474481-850153 X-HE-Meta: U2FsdGVkX19OQFV1RGGsvkeqIhJfHLcW9AsaKbyMqfUd8U9jognQjtImQw8N4rDDAfKlvGptEg0/XJDlJGUIGYcUGMjcyHOq1TS0ortny485vPzYVjK7RUn6vHpXQ0AFzsFpz0m3LdP3U09ofEtTsc2LIL0/FK2CNQvcFVVJ2cV7l9vavhWlfETMnLwHYQNBSEGJY59x32TXTBHOf0H/8gEwng2PguqP26aaFA1aQKguBHzF0bXLIP5floxklCHExQYcYaS5Sfy1UEOoNZsLm7cwQ7nI/SjtWTKVQyLzsRXqcz2xg7F+BVZcWVbNLtD/kILlbTBHxuo/NGJR//EfUB2GroiOLDGlXTXaJuWYZHcaMAEq2KFrj8PXK5y2zqPvqFWcAq1/Y7kCyySgYYHpja7Wn+DR3cioLrf12OIPR9NdJPv7UhV+Sv1tt78d6YRHdcl4SE7joB1uNBcWb5VcIOFiGAXNkBVMaQC5PTJaIepw7VZMyMRUOrnV3/HKMLAlC6+rgm6LU998PRjxtJO1WGPLVeN4Y11jlvTp7+bmcTwiFvRyce5U9Ne1CzBgPzyZSHBzQIZIqr0nWh3HdqroP1Q2MBeqWy6l7hh9JFnPxaYomPefuzvmRxEwlA2+nm+cyt83R2tSxX+XfYp/yzO0vnNefRYTOpiHrDMNargQnarjkVh1WzEFweJQwTMrR1LsPi9422I3IDGlda46N/xujw+JuRKLJ2ZiSJ1oBextFDOSMCySu610+vzCeVd/tQJvSwnuAGKexxgJ3NUNwb2UjbOfPU0fNlmO9GWYQAmUg//RseP3kE2B5Vf3Bo3F2M6tJ6SLTvwswDLRf3BbYRj1+4dtsrYTUizcGwzlC3HY6yEom17ZEyWR9fr/FSNHYn6L7f5t/ShZVfb/41p6gfQGHEiPH4MDDmySNpmSp31Vj8NaDZmJS4p7Lx6FkqJOJfdFat5uqW1ZGmYTOLgFms3 OmtOspdX vXbPuvyrx3My0vnzsoKXD2SkBOFdGwcD80OaVKXZrRhTGu0G385/75mL4pgeKQ3sgY34nWtNHzj83T627oOl3JGZDa7tFdaSIRVYuRAfI0PERYmMEeQC2w/fkeotrxW9f+/TMK84eUnrOVNT5Qf33tl9lUpvMPKvFmHzm/slBE5pYg7WFiXsO/3qRuDpDDeJoI6EJ0XvUOAbW+V0qYrOw+KnKWugI02YQ/1PdPz3OUi0TW1d0seFrqN4ld8zqXfoHRnrQWWV3usbQhU4WDmAG0I8c9206EWjKSRDRx6jFjGb0SICt9B9m7vnlY5mNS4E1+EO3wTTSADruixg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Jakub Kicinski wrote: > Maybe it's just me but I'd prefer to keep the clear rule that splice > operates on pages not slab objects. sendpage isn't only being used for splice(). Or were you referring to splicing pages into socket buffers more generally? > SIW is the software / fake implementation of RDMA, right? You couldn't have > picked a less important user :( ISCSI and sunrpc could both make use of this, as could ceph and others. I have patches for sunrpc to make it condense into a single bio_vec[] and sendmsg() in the server code (ie. nfsd) but for the moment, Chuck wanted me to just do the xdr payload. > > This offers the opportunity, at least in the future, to append slab data > > to an already-existing private fragment in the skbuff. > > Maybe we can get Eric to comment. The ability to identify "frag type" > seems cool indeed, but I haven't thought about using it to attach > slab objects. Unfortunately, you can't attach slab objects. Their lifetime isn't controlled by put_page() or folio_put(). kmalloc()/kfree() doesn't refcount them - they're recycled immediately. Hence why I was copying them. (Well, you could attach, but then you need a callback mechanism). What I'm trying to do is make it so that the process of calling sock_sendmsg() with MSG_SPLICE_PAGES looks exactly the same as without: You fill in a bio_vec[] pointing to your protocol header, the payload and the trailer, pointing as appropriate to bits of slab, static, stack data or ref'able pages, and call sendmsg and then the data will get copied or spliced as appropriate to the page type, whether the MSG_SPLICE_PAGES flag is supplied and whether the flag is supported. There are a couple of things I'd like to avoid: (1) having to call sock_sendmsg() more than once per message and (2) having sendmsg allocate more space and make a copy of data that you had to copy into a frag before calling sendmsg. David