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 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).