All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: "'Nelson, Shannon'" <shannon.nelson@intel.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	"Kong, Serey" <serey.kong@intel.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"nhorman@redhat.com" <nhorman@redhat.com>,
	"sassmann@redhat.com" <sassmann@redhat.com>,
	"jogreene@redhat.com" <jogreene@redhat.com>
Subject: RE: [net-next 03/12] i40e: Handle a single mss packet with more than 8 frags
Date: Mon, 17 Nov 2014 16:16:07 +0000	[thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1C9F1F9F@AcuExch.aculab.com> (raw)
In-Reply-To: <FC41C24E35F18A40888AACA1A36F3E418AD8F543@fmsmsx115.amr.corp.intel.com>

From: Nelson, Shannon
> > From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> > Sent: Saturday, November 15, 2014 10:22 AM
> >
> > On Fri, 2014-11-14 at 22:08 -0800, Jeff Kirsher wrote:
> > > From: Serey Kong <serey.kong@intel.com>
> > >
> > > This handles the case where a single packet with more than 8 data
> > > descriptors triggers a Malicious Driver Detect event in the device.
> > >
> 
> [...]
> 
> > > -	if (tx_flags & (I40E_TX_FLAGS_TSO | I40E_TX_FLAGS_FSO))
> > > +	if (tx_flags & (I40E_TX_FLAGS_TSO | I40E_TX_FLAGS_FSO)) {
> > >  		gso_segs = skb_shinfo(skb)->gso_segs;
> > > -	else
> > > +	} else {
> > >  		gso_segs = 1;
> > > +		if (skb_shinfo(skb)->nr_frags >= I40E_MAX_BUFFER_TXD)
> > > +			skb_linearize(skb);
> >
> > What exactly happens if skb_linearize() fails ?
> >
> > Is this "Malicious Driver Detect event" fatal or simply packet is
> > dropped without additional harm ?
> 
> This typically hits when there are many little TSO packets in a single MTU size frame.  The hardware
> doesn't like dealing with more than 8 separate buffers.

Except that a TSO packet is likely to be just under 64k and comprise of
a small header and 16 other fragments - most of which will be a complete 4k page.

If the hardware can't handle such packets then I suspect you can't actually
use TSO - which makes the device pretty useless.

If the problem is just too many fragment boundaries within a small number
of bytes then you need to detect that specific problem - probably merging
the adjacent small fragments into one that is large enough.

	David


  reply	other threads:[~2014-11-17 16:16 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-15  6:08 [net-next 00/12][pull request] Intel Wired LAN Driver Updates 2014-11-14 Jeff Kirsher
2014-11-15  6:08 ` [net-next 01/12] i40e: only warn once of PTP nonsupport in 100Mbit speed Jeff Kirsher
2014-11-15 21:20   ` Florian Fainelli
2014-11-15 22:38     ` [PATCH net-next] device: Add dev_<level>_once variants Joe Perches
2014-11-16 20:49       ` David Miller
2014-11-16 22:21         ` [PATCH net-next] netdevice: Neaten includes and forward declarations Joe Perches
2014-11-18 20:48           ` David Miller
2014-11-18 21:09             ` Joe Perches
2014-11-18 21:21               ` David Miller
2014-11-16 22:12     ` [PATCH net-next] i40e: Reduce stack in i40e_dbg_dump_desc Joe Perches
2014-11-17 21:06       ` David Miller
2014-11-17 21:30         ` Jeff Kirsher
2014-11-18  2:18     ` [PATCH (sent originally to netdev)] device: Add dev_<level>_once variants Joe Perches
2014-11-18  2:23       ` Jeff Kirsher
2014-11-15  6:08 ` [net-next 02/12] i40e: re-enable VFLR interrupt sooner Jeff Kirsher
2014-11-15  6:08 ` [net-next 03/12] i40e: Handle a single mss packet with more than 8 frags Jeff Kirsher
2014-11-15 18:21   ` Eric Dumazet
2014-11-17 14:15     ` David Laight
2014-11-17 14:31       ` Eric Dumazet
2014-11-17 14:40         ` David Laight
2014-11-17 14:55           ` Eric Dumazet
2014-11-17 16:04     ` Nelson, Shannon
2014-11-17 16:16       ` David Laight [this message]
2014-11-17 16:52         ` Eric Dumazet
2014-11-17 16:58         ` Eric Dumazet
2014-11-17 17:09           ` Eric Dumazet
2014-11-18  9:46           ` David Laight
2014-11-18 14:33             ` Eric Dumazet
2014-11-17 16:45       ` Eric Dumazet
2014-11-15  6:08 ` [net-next 04/12] i40e: Bump version to 1.1.23 Jeff Kirsher
2014-11-15  6:08 ` [net-next 05/12] i40e: Resume Port Tx after DCB event Jeff Kirsher
2014-11-15  6:08 ` [net-next 06/12] i40e: Add support to firmware CEE DCBX mode Jeff Kirsher
2014-11-15  6:08 ` [net-next 07/12] i40e: Check for LLDP AdminStatus before querying DCBX Jeff Kirsher
2014-11-15  6:08 ` [net-next 08/12] i40e: Update VEB's enabled_tc after reconfiguration Jeff Kirsher
2014-11-15  6:08 ` [net-next 09/12] i40e: Modify Tx disable wait flow in case of DCB reconfiguration Jeff Kirsher
2014-11-15  6:08 ` [net-next 10/12] i40e: Do not disable/enable FCoE VSI with DCB reconfig Jeff Kirsher
2014-11-15  6:08 ` [net-next 11/12] i40e: Prevent link flow control settings when PFC is enabled Jeff Kirsher
2014-11-15  6:08 ` [net-next 12/12] i40e: Set XPS bit mask to zero in DCB mode Jeff Kirsher
2014-11-16 20:04 ` [net-next 00/12][pull request] Intel Wired LAN Driver Updates 2014-11-14 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=063D6719AE5E284EB5DD2968C1650D6D1C9F1F9F@AcuExch.aculab.com \
    --to=david.laight@aculab.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jogreene@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@redhat.com \
    --cc=sassmann@redhat.com \
    --cc=serey.kong@intel.com \
    --cc=shannon.nelson@intel.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.