public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
	davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
	sassmann@redhat.com
Subject: Re: [net-next 02/11] ixgbe: Mask off check of frag_off as we only want fragment offset
Date: Fri, 12 Apr 2013 11:44:37 -0700	[thread overview]
Message-ID: <1365792277.4459.67.camel@edumazet-glaptop> (raw)
In-Reply-To: <516850E4.8020504@intel.com>

On Fri, 2013-04-12 at 11:22 -0700, Alexander Duyck wrote:

> I appreciate the desire to reuse, and what I meant was that since igb
> and ixgbe both use essentially the same function I could move it to one
> central location and both of them could use it as well as any other low
> level drivers that need to just quickly parse the header out of a linear
> block of data.  I just don't feel __skb_get_poff really does what I am
> looking for since it assumes it is working with a skb, not just a linear
> block of data.

Big deal.

Filling skb->data/head/len/data_len/network_offset and you're done in 3
cycles or so.

We are constrained by the ~250 cycles the cpu has for free to fetch 2
cache lines from the received frame.

>   If it could get broken up somehow so that it, or at
> least pieces of it could just be used on linear blocks of data then I
> might be more interested in reusing it.

But this is not going to happen. Our skb code is able to deal with
multiple areas (skb->head and frags). We are not going to duplicate it
for linear skbs 'only'

Thats your call obviously to maintain your own code, but consider you
fix this quite incredible bug only now. (All TCP data segments have the
DF flag set, so you were not pulling tcp headers)

  reply	other threads:[~2013-04-12 18:44 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-12 11:24 [net-next 00/11][pull request] Intel Wired LAN Driver Updates Jeff Kirsher
2013-04-12 11:24 ` [net-next 01/11] ixgbe: Support using build_skb in the case that jumbo frames are disabled Jeff Kirsher
2013-04-12 13:10   ` Eric Dumazet
2013-04-12 13:31     ` Eric Dumazet
2013-04-12 22:21   ` Ben Hutchings
2013-04-12 23:50     ` Alexander Duyck
2013-04-12 11:24 ` [net-next 02/11] ixgbe: Mask off check of frag_off as we only want fragment offset Jeff Kirsher
2013-04-12 13:28   ` Eric Dumazet
2013-04-12 13:45     ` Eric Dumazet
2013-04-12 16:38       ` Alexander Duyck
2013-04-12 16:51         ` Eric Dumazet
2013-04-12 18:22           ` Alexander Duyck
2013-04-12 18:44             ` Eric Dumazet [this message]
2013-04-12 20:12               ` Alexander Duyck
2013-04-12 20:29                 ` Eric Dumazet
2013-04-12 21:05                   ` Alexander Duyck
2013-04-12 21:12                     ` Eric Dumazet
2013-04-12 21:34                       ` Alexander Duyck
2013-04-12 21:40                         ` Eric Dumazet
2013-04-12 11:24 ` [net-next 03/11] ixgbe: don't do arithmetic operations on bitmasks Jeff Kirsher
2013-04-12 11:24 ` [net-next 04/11] ixgbe: Drop check for PAGE_SIZE from ixgbe_xmit_frame_ring Jeff Kirsher
2013-04-12 11:24 ` [net-next 05/11] ixgbe: Enable support for recognizing PCI-e Gen3 link speed Jeff Kirsher
2013-04-12 11:24 ` [net-next 06/11] ixgbe: create conversion functions from link_status to bus/speed Jeff Kirsher
2013-04-12 11:24 ` [net-next 07/11] ixgbe: enable devices with internal switch to read pci parent Jeff Kirsher
2013-04-12 11:24 ` [net-next 08/11] ixgbe: walk pci-e bus to find minimum width Jeff Kirsher
2013-04-13 21:28   ` Or Gerlitz
2013-04-15 20:48     ` Keller, Jacob E
2013-04-12 11:24 ` [net-next 09/11] ixgbe: fix MNG FW support when adapter not up Jeff Kirsher
2013-04-12 11:24 ` [net-next 10/11] ixgbe: Fix 1G link WoL Jeff Kirsher
2013-04-12 11:24 ` [net-next 11/11] ixgbe: bump version number Jeff Kirsher

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=1365792277.4459.67.camel@edumazet-glaptop \
    --to=eric.dumazet@gmail.com \
    --cc=alexander.h.duyck@intel.com \
    --cc=davem@davemloft.net \
    --cc=gospo@redhat.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=netdev@vger.kernel.org \
    --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