From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: Alexander Duyck <alexander.duyck@gmail.com>,
Jesse Brandeburg <jesse.brandeburg@gmail.com>
Cc: Dave Miller <davem@davemloft.net>,
Alexander Duyck <aduyck@mirantis.com>,
NetDEV list <netdev@vger.kernel.org>,
Neil Horman <nhorman@redhat.com>,
sassmann@redhat.com, John Greene <jogreene@redhat.com>,
Jesse Brandeburg <jesse.brandeburg@intel.com>
Subject: Re: [net-next 02/16] i40e/i40evf: Rewrite logic for 8 descriptor per packet check
Date: Tue, 29 Mar 2016 22:29:24 -0700 [thread overview]
Message-ID: <1459315764.2953.83.camel@intel.com> (raw)
In-Reply-To: <CAKgT0Udt1b8RYdh4Ex+34i+V4dRZWUuYWM=MpJK_DhuqGecjZQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]
On Tue, 2016-03-29 at 22:19 -0700, Alexander Duyck wrote:
> Minor correction here. This is 72 hex, which is 114 in decimal. The
> interesting bit I believe is the fact that we have both header and
> payload data in the same descriptor.
>
> You should probably check with your hardware team on this but I have
> a
> working theory on the issue. I'm thinking that because both header
> and payload are coming out of the same descriptor this must count as
> 2
> descriptors and not 1 when we compute the usage for the first
> descriptor. As such I do probably need to start testing at frag 0
> because the first payload can actually come out of the header region
> if the first descriptor includes both payload and data.
>
> I'll try to submit a patch for it tonight. If you can test it
> tomorrow I would appreciate it. Otherwise I will try setting up an
> environment to try and reproduce the issue tomorrow.
If you get it submitted tonight, I can have it ready in my tree for
testing for Jesse and the team when they get into the office tomorrow.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-03-30 5:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-19 9:53 [net-next 00/16][pull request] 40GbE Intel Wired LAN Driver Updates 2016-02-19 Jeff Kirsher
2016-02-19 9:53 ` [net-next 01/16] i40e/i40evf: Break up xmit_descriptor_count from maybe_stop_tx Jeff Kirsher
2016-02-19 9:53 ` [net-next 02/16] i40e/i40evf: Rewrite logic for 8 descriptor per packet check Jeff Kirsher
[not found] ` <CAEuXFEwPdnh8LNMXRP6fnasXO3P-iW-k1qPciXqayY+7c6=b0w@mail.gmail.com>
2016-03-30 0:34 ` Jesse Brandeburg
2016-03-30 2:20 ` Alexander Duyck
2016-03-30 5:19 ` Alexander Duyck
2016-03-30 5:29 ` Jeff Kirsher [this message]
2016-02-19 9:53 ` [net-next 03/16] i40e/i40evf: Move Tx checksum closer to TSO Jeff Kirsher
2016-02-19 9:53 ` [net-next 04/16] i40e: Add functions to blink led on 10GBaseT PHY Jeff Kirsher
2016-02-19 9:54 ` [net-next 05/16] i40e: Fix led blink capability for " Jeff Kirsher
2016-02-19 9:54 ` [net-next 06/16] i40e: Increase timeout when checking GLGEN_RSTAT_DEVSTATE bit Jeff Kirsher
2016-02-19 9:54 ` [net-next 07/16] i40e: Do not wait for Rx queue disable in DCB reconfig Jeff Kirsher
2016-02-19 9:54 ` [net-next 08/16] i40e: Fix for unexpected messaging Jeff Kirsher
2016-02-19 9:54 ` [net-next 09/16] i40e: Expose some registers to program parser, FD and RSS logic Jeff Kirsher
2016-02-19 9:54 ` [net-next 10/16] i40e: add check for null VSI Jeff Kirsher
2016-02-19 19:15 ` Underwood, JohnX
2016-02-19 19:41 ` David Miller
2016-02-19 19:48 ` Jeff Kirsher
2016-02-19 19:51 ` Underwood, JohnX
2016-02-19 20:57 ` David Miller
2016-02-19 9:54 ` [net-next 11/16] i40e: add adminq commands for Rx CTL registers Jeff Kirsher
2016-02-19 9:54 ` [net-next 12/16] i40e: implement and use Rx CTL helper functions Jeff Kirsher
2016-02-19 9:54 ` [net-next 13/16] i40e: Use the new rx ctl register helpers. Don't use AQ calls from clear_hw Jeff Kirsher
2016-02-19 9:54 ` [net-next 14/16] i40e: suspend scheduling during driver unload Jeff Kirsher
2016-02-19 9:54 ` [net-next 15/16] i40e: let go of the past Jeff Kirsher
2016-02-19 9:54 ` [net-next 16/16] i40e/i40evf: Bump i40e to 1.4.25 and i40evf to 1.4.15 Jeff Kirsher
2016-02-19 16:18 ` [net-next 00/16][pull request] 40GbE Intel Wired LAN Driver Updates 2016-02-19 David Miller
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=1459315764.2953.83.camel@intel.com \
--to=jeffrey.t.kirsher@intel.com \
--cc=aduyck@mirantis.com \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=jesse.brandeburg@gmail.com \
--cc=jesse.brandeburg@intel.com \
--cc=jogreene@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@redhat.com \
--cc=sassmann@redhat.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.