From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 250354218B5 for ; Tue, 16 Jun 2026 11:07:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781608025; cv=none; b=kVpefpyEUhn4o8s6FUVT45SQeAb1iYbnU7wybvvdpZ6Ld2mZw6BdC7EtiSOVQh15Hbymc04q1hCyhA+CnGKS3xAlNz6b1Y2EDVpN5cTAO9txsxbC9bC9zNzYkeLryWqvoA+SEAvyn/AaLB4DtmdnxQ0YN76DKthvQGP21p6XAzI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781608025; c=relaxed/simple; bh=8L7LN5GWKaXLjw308PhIswoJMOtulW5cOuUEITh9aLI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Hhg8IhD/8r8O+Riwq+rfryG21Ls7Mhu6ztj7nP2aTl0NQr5n7V5eqEPBfXpsHsXkX1UeHw0VA0HFTd/iHHqXOiajx/Uz5Nh+0NVITbK5QlSOJTWwlB9hwBpV4ibfnNwNsPj2qDDegqboSPn2saCUQc1+h68uCb77MC4VP+w8ag0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=s0dDammC; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="s0dDammC" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-490b23c828aso34125e9.1 for ; Tue, 16 Jun 2026 04:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1781608022; x=1782212822; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=eJ3fUZ+/EYmTkDXUK4ZNvux/ajtwZf6cg0AECRGmMnI=; b=s0dDammCBCw6WQnhJiLaI5FSDeCMnXGJ/V7Htq9NOoieO5xbrJ0d5WAfbAJmpiuHlb vgXDnLkT0H+yGynRrxSohSposzVOdjBV1XV2yB0oz9RQNX82FG900JTUiKfNmWG1tEVs EwT05VVo26DFdu3cntCQM+ZRwHnXaT+a2n1ptFfnx+O1gZCEG3NbT1jlaWt8NbY8Nw3R kHlM3+qrspfscti8TWIvs9Jj5klAfStgA1GUCFfkkgOnYdckm4Gs+PEUz1zNbsDQyjq8 FaEmkueTkkDjLGECDitqGDjkvCYY8jDaKXf9q84g7Ezj8fzECCNj1MwNvLrJXmkgzrm1 w8OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781608022; x=1782212822; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eJ3fUZ+/EYmTkDXUK4ZNvux/ajtwZf6cg0AECRGmMnI=; b=KNGKETU5mrkmoGlZnaIe/k52pmYcSodGVhOmV2hA4704Yp5vgeubrfJtrbkasMcqmv 25lmSpVM++TX7ytj3GsadriIjIKINkq4gby8JaBqrioAOEQj9rOW0j+FX/zkA+PEPFZF ROozmu1dZ5M0EYTu/8Epy/Kmc9HBiY2MYlCejMlIEKoH59KT3h9jW9qx3d70CVvPAYRx Iho0x/Y4ddy7r9kKKI7Wucd993nlyVDvIBS8xVX8RxKkJ083i7nnsYdmrYly+hkEjiUQ 9RpufYfVo8rPvoX6zV+668XBLELKDjV1BrvP4hZ78girf5dzQ75tS38qOIWskDYjfHEN mWBQ== X-Forwarded-Encrypted: i=1; AFNElJ/1JnlGF6PFaGj1g0ZOfA02n4Nz4f0QvN4/Z4or+CIdwMnwXkmLjDJHoC8kN4uXHC3t6UuOYN+G53OKjyo=@vger.kernel.org X-Gm-Message-State: AOJu0YyfvAxQOk55TUPo1Sc0ZRsWh6pKm8fUIxNb+8rrqCPQjBA1jOMo Ndvjiu+cugvdJputxlo0GNDM17ymGtPFip61U+/dtiB7njxIZtAjJLUbeQtWd/Drmg== X-Gm-Gg: Acq92OEkLOpD4QLo/6Dq5VI6wzyOoqQeQAqRH0JNwm2eLmp630ad9otkzcC73uJP91s aO+t9Do8O/oEHcLQoPn41dZV2Z6308R55tuA++NFRFuxrnc3KLEGbbf/eanuyMtxNSC2RtNL0Du 2bz+72ErQDSy1eGXHhAnrZKvKun0qyItgaHZ309KG/vg41L/+/2LqzKGjn8wbW58MUNWtx0U/Jo r0g7eTXsfaYE1JYStjXiIihHmQe4Ymb97Pu4bRUtWbNlFczap23y260MwklWnZi0LjRgA9Kr5Bg SKS/E/sI4JBQycQCZH8h0p2TWcqZWz8ujlBNE3STCoN4RlwLwMEYS2kNn5R3WDHw8vxep2FHuew lyEIM+6OeB1K06GJBJATaBAHNz2POQTws7k++i+bw6MTGCKhyGOxmYrQi26/uUfuyzwn+E0tV2x yLKeY4GZdmMsWRJPJElFnCtylKGPYCxIa4/rzR94LFcOmEObICLrmQlD4CWUiDww== X-Received: by 2002:a05:600c:c059:10b0:48a:5aa3:ac1e with SMTP id 5b1f17b1804b1-4923088e313mr879485e9.3.1781608022038; Tue, 16 Jun 2026 04:07:02 -0700 (PDT) Received: from google.com (140.240.76.34.bc.googleusercontent.com. [34.76.240.140]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4606f26393asm46289637f8f.5.2026.06.16.04.07.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2026 04:07:01 -0700 (PDT) Date: Tue, 16 Jun 2026 11:06:57 +0000 From: Mostafa Saleh To: Luigi Rizzo Cc: Jakub Kicinski , rizzo.unipi@gmail.com, m.szyprowski@samsung.com, robin.murphy@arm.com, willemb@google.com, kuniyu@google.com, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, gregkh@linuxfoundation.org, rafael@kernel.org, akpm@linux-foundation.org, david@kernel.org, netdev@vger.kernel.org, linux-mm@kvack.org, iommu@lists.linux.dev, driver-core@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] swiotlb: avoid double copy with swiotlb on tx socket Message-ID: References: <20260615234220.3946885-1-lrizzo@google.com> <20260615172535.080cf94f@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Jun 16, 2026 at 02:33:52AM +0200, Luigi Rizzo wrote: > On Tue, Jun 16, 2026 at 2:25 AM Jakub Kicinski wrote: > > > > On Mon, 15 Jun 2026 23:42:20 +0000 Luigi Rizzo wrote: > > > The use of swiotlb causes an extra data copy on I/O. For tx sockets, > > > especially with greedy senders, this has a high chance of happening in > > > the softirq handler for tx network interrupts, creating a significant > > > performance bottleneck. > > > > What's the use case? I associate swiotlb with debug / testing mostly, > > so it'd be useful for people like me to explain why you care. > > Ah sorry, I forgot to mention. > swiotlb is used in guest kernels for confidential computing VMs. > Ordinary memory pages are encrypted and the host or devices > have no way to decrypt them, so the kernel must use > unencrypted bounce buffers to exchange data with I/O devices. I started looking into the same problem recently, to reduce the bouncing in protected KVM (pKVM) confidential guests. My first attempt was to update dma_direct_map_phys() to skip bouncing and do inline memory decryption (for pKVM that is a hypercall which updates the stage-2 page tables), however, that was really slow compared to the memcpy in bouncing even for massive pages. My conclusion was similar that we need to solve this at construction by making this memory allocated from a pre-decrypted pool (which does not have to be part of the SWIOTLB) My initial idea was to teach some of the kernel subsystems (SKB, BLK, SLAB) about "CoCo allocators" that allocate decrypted memory, as this is not a net specific problem. I am still looking into this, I was planning to bring this up in the upcoming LPC. I will give this patch a try. However, I believe that we need a more generalised concept for CoCo pre-decrypted allocators in the kernel. Thanks, Mostafa > > cheers > luigi >