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
prev 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$(echo .)org \
--cc=haren@linux$(echo .)ibm.com \
--cc=horms@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nnac123@linux$(echo .)ibm.com \
--cc=ricklind@us$(echo .)ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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