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 12:41:35 -0700	[thread overview]
Message-ID: <20160330124135.000054c6@unknown> (raw)
In-Reply-To: <CAKgT0Ufb-_X-DD2jYkVJQwLZ-JBfWD2Biuhi6YaxWBeNy9K2fQ@mail.gmail.com>

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

> On Wed, Mar 30, 2016 at 10:20 AM, Sowmini Varadhan
> <sowmini.varadhan@oracle.com> wrote:
> > On (03/30/16 10:12), Alexander Duyck wrote:
> >> 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
> >> is not the case as I am also seeing the Tx hangs when I run the test
> >> with the frames being linearized.
> >
> > I'm not sure how important of a subtlety this is, but the actual
> > console log after the patch is the following:
> >
> >  i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> >  i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
> >  i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> >  i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
> >  i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> >
> > Comparing with what I'd pasted in the sourceforge thread earlier,
> > I see that it does not say "Hung Tx queue etc."  any more, though
> > it still resets.
> >
> > Not sure if that changed info is significant?
> 
> It might be.  Right now I am chasing down the Tx driver issue as that
> I what I am reproducing in my environment as well.

This gets "Even Uglier", I've turned off all offloads at my receiver,
enabled calling skb_linearize on *all* frames, which works fine for
scp, but the receiver shows > MSS sized frames on the wire for
rds-stress traffic.

This implies to me we have some issue with skb_linearize, possibly in
how the stack linearizes the data, or how the driver interprets the
linearized packets (which should always work)

Wheee......

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 12:41:35 -0700	[thread overview]
Message-ID: <20160330124135.000054c6@unknown> (raw)
In-Reply-To: <CAKgT0Ufb-_X-DD2jYkVJQwLZ-JBfWD2Biuhi6YaxWBeNy9K2fQ@mail.gmail.com>

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

> On Wed, Mar 30, 2016 at 10:20 AM, Sowmini Varadhan
> <sowmini.varadhan@oracle.com> wrote:
> > On (03/30/16 10:12), Alexander Duyck wrote:
> >> 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
> >> is not the case as I am also seeing the Tx hangs when I run the test
> >> with the frames being linearized.
> >
> > I'm not sure how important of a subtlety this is, but the actual
> > console log after the patch is the following:
> >
> >  i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> >  i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
> >  i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> >  i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
> >  i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> >
> > Comparing with what I'd pasted in the sourceforge thread earlier,
> > I see that it does not say "Hung Tx queue etc."  any more, though
> > it still resets.
> >
> > Not sure if that changed info is significant?
> 
> It might be.  Right now I am chasing down the Tx driver issue as that
> I what I am reproducing in my environment as well.

This gets "Even Uglier", I've turned off all offloads at my receiver,
enabled calling skb_linearize on *all* frames, which works fine for
scp, but the receiver shows > MSS sized frames on the wire for
rds-stress traffic.

This implies to me we have some issue with skb_linearize, possibly in
how the stack linearizes the data, or how the driver interprets the
linearized packets (which should always work)

Wheee......

  reply	other threads:[~2016-03-30 19:41 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         ` Jesse Brandeburg [this message]
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     ` [Intel-wired-lan] " Jesse Brandeburg
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=20160330124135.000054c6@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.