From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.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 D920C155C97 for ; Mon, 30 Mar 2026 17:07:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774890441; cv=none; b=m3M6hjptKrDCWtxq/mIyrqMYhbnwHY6IUL4K5RHMpBkCu7r61+FhV0KDLpaYJjh/ISyrpZ46gtNFEK9FlNcvaMDz9HaOD4/5RyDdSGH9dC+ARVd/0wH+HziLGWWqkq+FvVIEmkGjCKGBew0/TBWQzy1x8nJPfA8TFhDaOm1245g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774890441; c=relaxed/simple; bh=4R6RuBKBYUfoRqRS7x9RMplVEtjk9a5AM1rRdQYGRNU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tkzEPYu7tVMwOb9qE6YLCgxeTU5IycmhbEwPwmPKpZk+fG0j8Nk0JUOryH9kdamhTKaDqmS8hnrHuk1aHj9rSQFgPoWSCeecTN9xSJXjUDjgkac9t13VHuQeTPo7uk0jO1cQxSfhCgIYwPHJ+ePEw9bxVYYQxCJwCkBSkmSV0Uc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=dama.to; spf=none smtp.mailfrom=dama.to; dkim=pass (2048-bit key) header.d=dama-to.20230601.gappssmtp.com header.i=@dama-to.20230601.gappssmtp.com header.b=SIgBJmKI; arc=none smtp.client-ip=209.85.216.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=dama.to Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=dama.to Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=dama-to.20230601.gappssmtp.com header.i=@dama-to.20230601.gappssmtp.com header.b="SIgBJmKI" Received: by mail-pj1-f54.google.com with SMTP id 98e67ed59e1d1-35691a231a7so2873132a91.3 for ; Mon, 30 Mar 2026 10:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dama-to.20230601.gappssmtp.com; s=20230601; t=1774890439; x=1775495239; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=C2ckhJIZxyCoIszlFarfOvV6+4UuzFAlnFaLl53XZ3c=; b=SIgBJmKIR5Rul8mOcu7f6kBrOcexNFJBGm6I0vwFjjiBc/Qz19AbbuEu+IyJob475U jq5VcHdBWclKA0KHo/Bh+3dL9v6LE5J/UJY4HUI/a7feqHDBqdPRpM9TB7J84AHUIjOk ysfy2I/LJLUl8s4vx7g/Iys4Znpfp5px+Lx8C7KieuG8u53hFC2FpzNamFcfjSsif/mQ D+3zUCpKjgVSTUCVJwuWYIL/+LmSnXRP3HxmQpSSijynx94dUnf68BKMl2oPJBuXbVjQ rcogqthv/cgIm0iGJbkAxxFZ0ii7Nfaj55uwNXTlrLJ8DEv++TXI+D2psitwCiQSk4Yd AWFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774890439; x=1775495239; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=C2ckhJIZxyCoIszlFarfOvV6+4UuzFAlnFaLl53XZ3c=; b=Qf5K/sRKj92q+m6oVb8Sy1ourlVAN5M8AwnsJwevnqq/mndNJbbY0VMJ/0BdXRJOhu p92E4yv76hg8JEqyzDT6UVhcEZk+Ex4tvwa7CX3LV82DA6dS/XhXJ4G7mpJiDC8s4bdI Rzl0our/CC/P0hyyMuevEitN32tZrefmwimbsbkmhJR5gpTDNL+KQB+XkCPjWksPzgKn 67V2U7j4TAUFs9isNJRplxAWjL9wJBq8q3MH/21Y25Wv647RA8AJiEsImDNl7HduwuRE 4iDajf83Sx2v6NZ9/vaWSYR1cMU5WlpnJwmuiqtQel7zVgOydvc9miG9xhxx04NY5JLh rDzg== X-Forwarded-Encrypted: i=1; AJvYcCVsrxbTPRhWI4ArSoRgMpKtk/vpxvd+HQu/nzQ6+omClY7M4teaujwOsSTzekDlOuohKdASRkRa9+jVDAo=@vger.kernel.org X-Gm-Message-State: AOJu0YxJO6zxitofTuAKhMTxKVaj9+drryOY87eOpBPWF9wUuvCq+9hs iXRNEfd01lMMYcac78V2791OFEq8OH4L6LGmSSQoZE7Ue62LET4OP2Ve2PRvS7Xfa0E= X-Gm-Gg: ATEYQzxgNGRaez2CUKruvmglKaJg8qRtVcMT8gVeVvoXxGTmmcjAn5NsanXsFEQ5jol btgjbM+STbtBdqZthhxFogjj/lqbhc4khEujQv/8FUNelRLL1kdA8wzIuXNQMZgpIdm2FfJSE9P ibrZiYP+6bBW+jhFlN4msc3uSKnCL6v97InApL1JCiNPXxkAoPup4NLjRFlXLJVYjPM7deLTwkF n7S3Nu2RA8n8YjmKhMPsCArzIXOu9iDVeOxWdr4J1O6wyGFJEWqrzc2VTEFfvOhQMMrvvUB3LnK 1LPoL3aK4Xmiac131ZrexpgJRnPMvQ0zK2C04OUZTXxHx2/LFsDFv4qbPoP/hOSSR3c95LU0vXs Ubuz6nXs2bQmcHZbq7/xAwyV81q5eYt8oV8UDT9HwsnGFLiQ4JzZp/gzb13XYTVMnV7++qO3MaX zzo3jz X-Received: by 2002:a17:90b:4a8a:b0:356:35a5:4a64 with SMTP id 98e67ed59e1d1-35c2ff1e0f2mr11509143a91.4.1774890439144; Mon, 30 Mar 2026 10:07:19 -0700 (PDT) Received: from localhost ([2a03:2880:2ff:51::]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-35c2ec9c8d8sm4126258a91.12.2026.03.30.10.07.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Mar 2026 10:07:18 -0700 (PDT) Date: Mon, 30 Mar 2026 10:07:17 -0700 From: Joe Damato To: Jakub Kicinski Cc: netdev@vger.kernel.org, Michael Chan , "David S. Miller" , Eric Dumazet , Paolo Abeni , andrew+netdev@lunn.ch, horms@kernel.org, pavan.chebbi@broadcom.com, linux-kernel@vger.kernel.org, leon@kernel.org Subject: Re: [net-next v6 09/12] net: bnxt: Add SW GSO completion and teardown support Message-ID: Mail-Followup-To: Joe Damato , Jakub Kicinski , netdev@vger.kernel.org, Michael Chan , "David S. Miller" , Eric Dumazet , Paolo Abeni , andrew+netdev@lunn.ch, horms@kernel.org, pavan.chebbi@broadcom.com, linux-kernel@vger.kernel.org, leon@kernel.org References: <20260326235238.2940471-1-joe@dama.to> <20260326235238.2940471-10-joe@dama.to> <20260329152236.6ad729e6@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=us-ascii Content-Disposition: inline In-Reply-To: <20260329152236.6ad729e6@kernel.org> On Sun, Mar 29, 2026 at 03:22:36PM -0700, Jakub Kicinski wrote: > On Thu, 26 Mar 2026 16:52:28 -0700 Joe Damato wrote: > > + if (head_buf->is_sw_gso == BNXT_SW_GSO_LAST) { > > + if (dma_use_iova(&head_buf->iova_state)) > > + dma_iova_destroy(&pdev->dev, > > + &head_buf->iova_state, > > + head_buf->iova_total_len, > > + DMA_TO_DEVICE, 0); > > Do we have to expose the dma_use_iova() stuff to the driver at all? > Could we have a function the driver is supposed to call to clean up, > always, and what the function does is up to the TSO lib? I could add a tso_dma_map_destroy(dev, iova_state, len) that the driver calls, but the driver would still need to stash iova_state and total_len on the ring. That would be easiest, but I'm not sure if you were thinking that the IOVA stuff should be as opague as possible? Because if you do want it to be as opague as possible, maybe: /* Add a struct to tso.h to track completion state */ struct tso_dma_map_completion_state { struct dma_iova_state iova_state; size_t total_len; } Add a save function: tso_dma_map_completion_save(map, completion_state); And then: - the bnxt sw bd stores a struct tso_dma_map_completion_state. - xmit calls tso_dma_map_completion_save to store the iova_state - completion calls tso_dma_complete(dev, &head_buf->completion_state) LMK if you meant the easier way or the more opague way?