netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Gal Pressman <gal@nvidia.com>
Cc: Shay Agroskin <shayagr@amazon.com>,
	David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, "Woodhouse, David" <dwmw@amazon.com>,
	"Machulsky, Zorik" <zorik@amazon.com>,
	"Matushevsky, Alexander" <matua@amazon.com>,
	Saeed Bshara <saeedb@amazon.com>, "Wilson, Matt" <msw@amazon.com>,
	"Liguori, Anthony" <aliguori@amazon.com>,
	"Bshara, Nafea" <nafea@amazon.com>,
	"Belgazal, Netanel" <netanel@amazon.com>,
	"Saidi, Ali" <alisaidi@amazon.com>,
	"Herrenschmidt, Benjamin" <benh@amazon.com>,
	"Kiyanovski, Arthur" <akiyano@amazon.com>,
	"Dagan, Noam" <ndagan@amazon.com>,
	"Arinzon, David" <darinzon@amazon.com>,
	"Itzko, Shahar" <itzko@amazon.com>,
	"Abboud, Osama" <osamaabb@amazon.com>
Subject: Re: [PATCH v4 net-next 1/5] ethtool: Add support for configuring tx_push_buf_len
Date: Thu, 16 Mar 2023 13:42:44 -0700	[thread overview]
Message-ID: <20230316134244.56727793@kernel.org> (raw)
In-Reply-To: <30cb3990-80ce-ca07-6d73-cdc00d0ad7b8@nvidia.com>

On Thu, 16 Mar 2023 13:57:26 +0200 Gal Pressman wrote:
> On 14/03/2023 17:38, Shay Agroskin wrote:
> >> Shay, could you add a paragraph in the docs regarding copybreak in v5?  
> > 
> > Document that tx_copybreak defines the threshold below which the packet
> > is copied into a preallocated DMA'ed buffer and that tx_push_buf defines
> > the same but for device memory?
> > Are we sure we want to make this distinction ? While the meaning of both
> > params can overlap in their current definition, the motivation to use
> > them is pretty different.
> > A driver can implement both for different purposes (and still copy both
> > into the device).  
> 
> I don't understand what it means to implement both.

If skb head is large you can copy part into the iomem, part into 
a pre-mapped space.

> It's confusing because both parameters result in skipping the DMA map
> operation, but their usage motivation is different?
> What are we instructing our customers? Use copybreak when your iommu is
> slow, but when should they use this new parameter?

Your customers? Is mlx5 going to implement the iomem based push which
needs explicit slot size control?

> IMO, a reasonable way to use both would be to only account for the
> tx_push_buf_len when tx_push is enabled, otherwise use copybreak.

I thought Shay already agreed. Let's get the v5 out.

  reply	other threads:[~2023-03-16 20:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-09 13:13 [PATCH v4 net-next 0/5] Add tx push buf len param to ethtool Shay Agroskin
2023-03-09 13:13 ` [PATCH v4 net-next 1/5] ethtool: Add support for configuring tx_push_buf_len Shay Agroskin
2023-03-09 16:25   ` Simon Horman
2023-03-09 17:15   ` Gal Pressman
2023-03-10  6:53     ` Jakub Kicinski
2023-03-12 12:41       ` Gal Pressman
2023-03-13 19:09         ` Jakub Kicinski
2023-03-14 15:38           ` Shay Agroskin
2023-03-16 11:57             ` Gal Pressman
2023-03-16 20:42               ` Jakub Kicinski [this message]
2023-03-14 15:46     ` Shay Agroskin
2023-03-09 13:13 ` [PATCH v4 net-next 2/5] net: ena: Make few cosmetic preparations to support large LLQ Shay Agroskin
2023-03-09 16:28   ` Simon Horman
2023-03-09 13:13 ` [PATCH v4 net-next 3/5] net: ena: Add an option to configure large LLQ headers Shay Agroskin
2023-03-09 16:28   ` Simon Horman
2023-03-09 13:13 ` [PATCH v4 net-next 4/5] net: ena: Recalculate TX state variables every device reset Shay Agroskin
2023-03-09 13:13 ` [PATCH v4 net-next 5/5] net: ena: Add support to changing tx_push_buf_len Shay Agroskin
2023-03-09 16:28   ` Simon Horman
2023-03-10  6:54   ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230316134244.56727793@kernel.org \
    --to=kuba@kernel.org \
    --cc=akiyano@amazon.com \
    --cc=aliguori@amazon.com \
    --cc=alisaidi@amazon.com \
    --cc=benh@amazon.com \
    --cc=darinzon@amazon.com \
    --cc=davem@davemloft.net \
    --cc=dwmw@amazon.com \
    --cc=gal@nvidia.com \
    --cc=itzko@amazon.com \
    --cc=matua@amazon.com \
    --cc=msw@amazon.com \
    --cc=nafea@amazon.com \
    --cc=ndagan@amazon.com \
    --cc=netanel@amazon.com \
    --cc=netdev@vger.kernel.org \
    --cc=osamaabb@amazon.com \
    --cc=saeedb@amazon.com \
    --cc=shayagr@amazon.com \
    --cc=zorik@amazon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).