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 1B7ECEB64DA for ; Thu, 22 Jun 2023 19:41:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3BC458D0002; Thu, 22 Jun 2023 15:41:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 36D558D0001; Thu, 22 Jun 2023 15:41:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 234B18D0002; Thu, 22 Jun 2023 15:41:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 168668D0001 for ; Thu, 22 Jun 2023 15:41:12 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id DCE1E1401BF for ; Thu, 22 Jun 2023 19:41:11 +0000 (UTC) X-FDA: 80931402342.13.F5DFB88 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf10.hostedemail.com (Postfix) with ESMTP id F2B19C0013 for ; Thu, 22 Jun 2023 19:41:08 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AdyH59HZ; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf10.hostedemail.com: domain of dhowells@redhat.com designates 170.10.133.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=1687462869; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=QZ2Xje2ved2ulckSwXdjtr8v/wsld5XIT0hNVNJkMSk=; b=HmsXb88L18EejTtR45ddLi8i/rjZi8Cx8Q48yVaCubeaRKJ40NlIIcEoa3oo4oQDw1MeUF K9gSzXImySwprlq4yTEHOqi4s4f4eN83GoDfjq0jLs2lNJe4aqrWs0x88uLJQSSP/uVUHd okj7XUB55tVM9lups5huM588K5Bagh0= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AdyH59HZ; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf10.hostedemail.com: domain of dhowells@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687462869; a=rsa-sha256; cv=none; b=QrVSG/aKCAMf8ESLm373L9nqs6Nadm2g0L2RXnjf+0eq/G1ade5N4pRunV9nXaXaNjl2zR JOiRir2E9pbtggsFRVVlYsAFI+D4brvP8rE7dps5C4mdgYAiP2x14/B+rFZfkDhmKoN/lz USqkAdqB1bbAT6IzV1jMyylOHEMD0u0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687462868; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QZ2Xje2ved2ulckSwXdjtr8v/wsld5XIT0hNVNJkMSk=; b=AdyH59HZDmDGL5mvCdreRQMOZcZq/yWm2oW1p0A0h491edVMe3W1Qg0iaQ56EZdma0dVFq 0zooN7EPQWc3CAYpw8baKJv8lsFb0ywPoSzv3SELOcPpaiMh1xxNR3Nuj2s/dV9qThGoS7 FWBBsiWDHJJPrwTID3wDKBSzqTJGYYU= 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-460-zM8z2jPxM6Ge_eoEK0X5CQ-1; Thu, 22 Jun 2023 15:41:03 -0400 X-MC-Unique: zM8z2jPxM6Ge_eoEK0X5CQ-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2762A282380B; Thu, 22 Jun 2023 19:40:46 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.42.28.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id C1AEC492B01; Thu, 22 Jun 2023 19:40:43 +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: <20230622111234.23aadd87@kernel.org> References: <20230622111234.23aadd87@kernel.org> <20230620145338.1300897-1-dhowells@redhat.com> <20230620145338.1300897-2-dhowells@redhat.com> To: Jakub Kicinski Cc: dhowells@redhat.com, netdev@vger.kernel.org, Alexander Duyck , "David S. Miller" , Eric Dumazet , 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: <1952673.1687462843.1@warthog.procyon.org.uk> Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jun 2023 20:40:43 +0100 Message-ID: <1952674.1687462843@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: F2B19C0013 X-Stat-Signature: 4p9cd8angwyrqmtobobmsmcqpkkt9dy1 X-Rspam-User: X-HE-Tag: 1687462868-119251 X-HE-Meta: U2FsdGVkX1/8DA1EqLFQ4AKRElJPLJxaTkCFFcUFZOELEnOmyxq+MukQbJKyB1X1ZcFaI/BIwn6C9hv/u0H1b3+Ug+P2PWSvk+e0duATRRBfvkDigg14m0verYF+faW37+amcak6+8umjQQ68LweT1bkToOCCS8PyFb/dbgzwIltWXDu6osPv/BAT8jQH8L/T7apUTmvc+zE1SELT/+u+nW4F7NzdFGTy317eoEMbrO/ZIR5FJn9vb31utfLvNEjKWH1DcRhrr+DiHI2dPcwDzdxuqz06PSzF9KNr8waSN8QgXt5afT7nNwSQ/VDTcTXY/7CzVfAj6dygrti+dyNQmKtmWcrlxUWvygCpxGpjZa8baSqybOjOPLgqQty57tc2/Cdd2BXbqyItrYyXX/Qz0t+sgVZLOLop4rkXx44qi2Btqv0m849fX2ZyvuAFz73Q6wfsst+ptihzxkenuh6Titks8FIvMwS+52Uf9oynXV8BwOYigwPkyHyeTPyT5KFWfu19eWF08ZQslHx5vzfI5t1WmrtBVe64sDwRtlldmK/2otSUhErCw53+0qzxA+C3aClKaqFcTpg4/buxE2LmZjTmwwPKuSRAIiHc8ZdBfp/JOCzqtEUxtNkoQkeATwEaSM+RbAIMnIjKTfABwECeZrqlKqi/LAAf4gw25ZtSxyXwEAnVOuKWGuQMGbD3L5eoDRx1iN7DIB6g+VT4KCLZknmX/pfR0Sov3RQF1BRxPe2kkWHQvDZqgmsboC89QQURPHtMDndycnHw40O9c5+EYoOYj3qzfBFMg6HXsvJq+YurTsofDob0HurzHtdR0OuxSlDiTVoj2M0yD+BSUzF89LA4MQPPbQAQ3uiNbqF+Z/Gs6Eu9tEzEzzTDZq1NLDH+7bidRMTurYtajrRBv9CYWFCzFIDqpA3BimveAodIzZ+fwsPN3ea+8Zv/qrgcV9Pkp9WIriRcymFfhPGgUg Ze5/jFH9 lHmfnSOenrfh7tHMXpfmYLQC1mrww782MmqNAjPQksNxkjxI2FIjuqciW5VR3TkRkiqkynGlTkP0Mm4fWDkFvN8a9XknYeJ4U++rrYmdMeExSObJEkk1DLPm69X8nUg5vLNzxR0UkL2XlGr9bKxh0JZ1YF7f9Aymx1bHoJi/1wNnVI81wrhwYxWFtQ4hz8Z4H5RbRH9iO8yHqzaVD959WgSzUS6I1qZzHXpctBG8Q/un35K61M/sdkdG/28emtHbgect0A5b1LaPm2SX8r8/tMuRVt+1pJZQWcS/+b/Z/GfcJQWn3LfDiR6d0V9IqN22qBDdSW3LmHpAkkL4= 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: > > If sendmsg() is passed MSG_SPLICE_PAGES and is given a buffer that con= tains > > some data that's resident in the slab, copy it rather than returning E= IO. > = > How did that happen? I thought MSG_SPLICE_PAGES comes from former > sendpage users and sendpage can't operate on slab pages. Some of my patches, take the siw one for example, now aggregate all the bi= ts that make up a message into a single sendmsg() call, including any protoco= l header and trailer in the same bio_vec[] as the payload where before it wo= uld have to do, say, sendmsg+sendpage+sendpage+...+sendpage+sendmsg. I'm trying to make it so that I make the minimum number of sendmsg calls (ie. 1 where possible) and the loop that processes the data is inside of t= hat. This offers the opportunity, at least in the future, to append slab data t= o an already-existing private fragment in the skbuff. > The locking is to local_bh_disable(). Does the milliont^w new frag > allocator have any additional benefits? It is shareable because it does locking. Multiple sockets of multiple protocols can share the pages it has reserved. It drops the lock around c= alls to the page allocator so that GFP_KERNEL/GFP_NOFS can be used with it. Without this, the page fragment allocator would need to be per-socket, I think, or be done further up the stack where the higher level drivers woul= d have to have a fragment bucket per whatever unit they use to deal with the lack of locking. Doing it here makes cleanup simpler since I just transfer my ref on the fragment to the skbuff frag list and it will automatically be cleaned up w= ith the skbuff. Willy suggested that I just allocate a page for each thing I want to copy,= but I would rather not do that for, say, an 8-byte bit of protocol data. David