All of lore.kernel.org
 help / color / mirror / Atom feed
From: patchwork-bot+netdevbpf@kernel.org
To: Nick Child <nnac123@linux.ibm.com>
Cc: netdev@vger.kernel.org, horms@kernel.org, haren@linux.ibm.com,
	ricklind@us.ibm.com
Subject: Re: [PATCH net v2 0/1] ibmvnic: Fix for send scrq direct
Date: Fri, 04 Oct 2024 19:10:36 +0000	[thread overview]
Message-ID: <172806903625.2708740.7897093517925120680.git-patchwork-notify@kernel.org> (raw)
In-Reply-To: <20241001163200.1802522-1-nnac123@linux.ibm.com>

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Tue,  1 Oct 2024 11:31:59 -0500 you wrote:
> This is a v2 of a patchset (now just patch) which addresses a
> bug in a new feature which is causing major link UP issues with
> certain physical cards.
> 
> For a full summary of the issue:
>   1. During vnic initialization we get the following values from vnic
>      server regarding "Transmit / Receive Descriptor Requirement" (see
>       PAPR Table 584. CAPABILITIES Commands):
>     - LSO Tx frame = 0x0F , header offsets + L2, L3, L4 headers required
>     - CSO Tx frame = 0x0C , header offsets + L2 header required
>     - standard frame = 0x0C , header offsets + L2 header required
>   2. Assume we are dealing with only "standard frames" from now on (no
>      CSO, no LSO)
>   3. When using 100G backing device, we don't hand vnic server any header
>      information and TX is successful
>   4. When using 25G backing device, we don't hand vnic server any header
>     information and TX fails and we get "Adapter Error" transport events.
> The obvious issue here is that vnic client should be respecting the 0X0C
> header requirement for standard frames.  But 100G cards will also give
> 0x0C despite the fact that we know TX works if we ignore it. That being
> said, we still must respect values given from the managing server. Will
> need to work with them going forward to hopefully get 100G cards to
> return 0x00 for this bitstring so the performance gains of using
> send_subcrq_direct can be continued.
> 
> [...]

Here is the summary with links:
  - [net,v2,1/1] ibmvnic: Inspect header requirements before using scrq direct
    https://git.kernel.org/netdev/net/c/de390657b5d6

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



      parent reply	other threads:[~2024-10-04 19:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-01 16:31 [PATCH net v2 0/1] ibmvnic: Fix for send scrq direct Nick Child
2024-10-01 16:32 ` [PATCH net v2 1/1] ibmvnic: Inspect header requirements before using " Nick Child
2024-10-03 14:39   ` Simon Horman
2024-10-04 19:10 ` patchwork-bot+netdevbpf [this message]

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=172806903625.2708740.7897093517925120680.git-patchwork-notify@kernel.org \
    --to=patchwork-bot+netdevbpf@kernel.org \
    --cc=haren@linux.ibm.com \
    --cc=horms@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nnac123@linux.ibm.com \
    --cc=ricklind@us.ibm.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.