All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.