All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
Date: Wed, 30 Mar 2016 11:38:27 -0700	[thread overview]
Message-ID: <20160330113827.00002967@unknown> (raw)
In-Reply-To: <CAKgT0UdTgaeamyLetGPK0mqMNS-80BTc8t-WdSGJuuLDfz4JOg@mail.gmail.com>

On Wed, 30 Mar 2016 10:12:51 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:

> On Wed, Mar 30, 2016 at 10:00 AM, Sowmini Varadhan
> <sowmini.varadhan@oracle.com> wrote:
> > On (03/29/16 23:44), Alexander Duyck wrote:
> >> This patch has been sanity checked only.  I cannot yet guarantee it
> >> resolves the original issue that was reported.  I'll try to get a
> >> reproduction environment setup tomorrow but I don't know how long that
> >> should take.
> >
> > I tried this out with rds-stress on my test-pair, unfortunately, I
> > still see the Tx hang.
> >
> > Setting up the test is quite easy- for reference, the instructions
> > are here:
> >    https://sourceforge.net/p/e1000/mailman/message/34936766/
> 
> Yeah.  The patch was sort of a knee-jerk reaction to being told that
> the patch referenced caused a regression.  From what I can tell that

Thanks for working so hard on the patch Alex, I need to apologize, as
the original test appears to fail as well with 1.3.46-k (a previous
driver to your patch) and I thought we had already tested that, but I
was wrong.

This is not a regression, but likely just an undetected "bug" that we
need to work out.

> is not the case as I am also seeing the Tx hangs when I run the test
> with the frames being linearized.

That doesn't make much sense unless it is something about how we are
setting up the offload.  I troubleshoot by disabling the PFR from the
MDD code, then disabling tx timeout via debugfs, and using debugfs to
dump the descriptor ring after the MDD event fires.
 
> I'll do some research this morning to see if I can find a root cause.
> Unfortunately the malicious driver detection isn't very well
> documented so I can't be certain what is causing it to be triggered.

I'm still looking at this too and appreciate the help.

WARNING: multiple messages have this Message-ID (diff)
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Sowmini Varadhan <sowmini.varadhan@oracle.com>,
	Alexander Duyck <aduyck@mirantis.com>,
	Netdev <netdev@vger.kernel.org>,
	intel-wired-lan <intel-wired-lan@lists.osuosl.org>,
	Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
	jesse.brandeburg@intel.com
Subject: Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
Date: Wed, 30 Mar 2016 11:38:27 -0700	[thread overview]
Message-ID: <20160330113827.00002967@unknown> (raw)
In-Reply-To: <CAKgT0UdTgaeamyLetGPK0mqMNS-80BTc8t-WdSGJuuLDfz4JOg@mail.gmail.com>

On Wed, 30 Mar 2016 10:12:51 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:

> On Wed, Mar 30, 2016 at 10:00 AM, Sowmini Varadhan
> <sowmini.varadhan@oracle.com> wrote:
> > On (03/29/16 23:44), Alexander Duyck wrote:
> >> This patch has been sanity checked only.  I cannot yet guarantee it
> >> resolves the original issue that was reported.  I'll try to get a
> >> reproduction environment setup tomorrow but I don't know how long that
> >> should take.
> >
> > I tried this out with rds-stress on my test-pair, unfortunately, I
> > still see the Tx hang.
> >
> > Setting up the test is quite easy- for reference, the instructions
> > are here:
> >    https://sourceforge.net/p/e1000/mailman/message/34936766/
> 
> Yeah.  The patch was sort of a knee-jerk reaction to being told that
> the patch referenced caused a regression.  From what I can tell that

Thanks for working so hard on the patch Alex, I need to apologize, as
the original test appears to fail as well with 1.3.46-k (a previous
driver to your patch) and I thought we had already tested that, but I
was wrong.

This is not a regression, but likely just an undetected "bug" that we
need to work out.

> is not the case as I am also seeing the Tx hangs when I run the test
> with the frames being linearized.

That doesn't make much sense unless it is something about how we are
setting up the offload.  I troubleshoot by disabling the PFR from the
MDD code, then disabling tx timeout via debugfs, and using debugfs to
dump the descriptor ring after the MDD event fires.
 
> I'll do some research this morning to see if I can find a root cause.
> Unfortunately the malicious driver detection isn't very well
> documented so I can't be certain what is causing it to be triggered.

I'm still looking at this too and appreciate the help.

  parent reply	other threads:[~2016-03-30 18:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-30  6:44 [Intel-wired-lan] [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet Alexander Duyck
2016-03-30  6:44 ` Alexander Duyck
2016-03-30 17:00 ` [Intel-wired-lan] " Sowmini Varadhan
2016-03-30 17:00   ` Sowmini Varadhan
2016-03-30 17:12   ` [Intel-wired-lan] " Alexander Duyck
2016-03-30 17:12     ` Alexander Duyck
2016-03-30 17:20     ` [Intel-wired-lan] " Sowmini Varadhan
2016-03-30 17:20       ` Sowmini Varadhan
2016-03-30 17:35       ` [Intel-wired-lan] " Alexander Duyck
2016-03-30 17:35         ` Alexander Duyck
2016-03-30 19:41         ` [Intel-wired-lan] " Jesse Brandeburg
2016-03-30 19:41           ` Jesse Brandeburg
2016-03-30 20:09           ` [Intel-wired-lan] " Sowmini Varadhan
2016-03-30 20:09             ` Sowmini Varadhan
2016-03-30 20:15             ` [Intel-wired-lan] " Eric Dumazet
2016-03-30 20:15               ` Eric Dumazet
2016-03-30 20:40               ` [Intel-wired-lan] " Sowmini Varadhan
2016-03-30 20:40                 ` Sowmini Varadhan
2016-03-30 21:20           ` [Intel-wired-lan] " Alexander Duyck
2016-03-30 21:20             ` Alexander Duyck
2016-03-30 23:06             ` [Intel-wired-lan] " Alexander Duyck
2016-03-30 23:06               ` Alexander Duyck
2016-03-30 18:38     ` Jesse Brandeburg [this message]
2016-03-30 18:38       ` Jesse Brandeburg

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=20160330113827.00002967@unknown \
    --to=jesse.brandeburg@intel.com \
    --cc=intel-wired-lan@osuosl.org \
    /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.