All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Nick Krause <xerofoify@gmail.com>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	Koehrer Mathias <mathias.koehrer@etas.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH] Fix e1000e with Intel 82572EI that has no hardware timestamp support
Date: Wed, 06 Aug 2014 13:19:37 -0700	[thread overview]
Message-ID: <53E28DD9.6060503@intel.com> (raw)
In-Reply-To: <CAPDOMVgHmQeqOGj1MegRa=gusGXMn5t7cwCNnutpc1_q_fzyYg@mail.gmail.com>

On 08/06/2014 12:03 PM, Nick Krause wrote:
> On Wed, Aug 6, 2014 at 11:26 AM, Alexander Duyck
> <alexander.h.duyck@intel.com> wrote:
>> On 08/06/2014 08:21 AM, Alexander Duyck wrote:
>>> On 08/06/2014 08:09 AM, Henrique de Moraes Holschuh wrote:
>>>> On Wed, Aug 6, 2014, at 11:30, Sergei Shtylyov wrote:
>>>>> On 8/6/2014 6:27 PM, Koehrer Mathias (ETAS/ESW5) wrote:
>>>>>
>>>>>> With the Intel 82527EI (driver: e1000e) there is an issue when running
>>>>>> the ptpd2 program, that leads to a kernel oops.
>>>>>> The reason is here that in e1000_xmit_frame() a work queue will be
>>>>>> scheduled that has not been initialized in this case.
>>>>>> The work queue "tx_hwstamp_work" will only be initialized if
>>>>>> adapter->flags & FLAG_HAS_HW_TIMESTAMP set.
>>>>>> This check is missing in e1000_xmit_frame().
>>>>>
>>>>>> The following patch adds the missing check.
>>>>>
>>>>>     OK, but this time you forgot your sign-off. :-)
>>>>
>>>> Also, shouldn't the added test be inside the unlikely() ?
>>>>
>>>
>>> That shouldn't be necessary, but it might be better to place the new
>>> check after the unlikely.  So you do the unlikely check first, then the
>>> adapter check to see if we support Tx timestamping.  That way we can
>>> avoid any unnecessary checks in the adapter structure.
>>>
>>> Thanks,
>>>
>>> Alex
>>>
>>
>>
>> Actually you might want to even take it one step further and break out
>> the test as follows (note this is only pseudo-code:
>>   unlikely(skb->tx_flags & HW_TSTAMP) &&
>>   (adapter->flags & HAS_HW_TSTAMP) &&
>>   !adapter->tx_hwtstamp_skb
>>
>> There isn't much point in wrapping the entire statement in unlikely, by
>> wrapping just the first test the rest of the conditional checks can be
>> pushed into the branch which will likely require a jump to some remote
>> block of code and should streamline the hot-path.
>>
>> Thanks,
>>
>> Alex
> 
> Alex,
> Has this patch been resent or not. If not I can clean it up and sent
> as my own patch against linus's tree.
> Regards NIck
> 

Nick,

Please give Mathias a chance to complete his own patch.  Also this is
would be against Dave Miller's net tree, not Linus's tree.

Thanks,

Alex

  parent reply	other threads:[~2014-08-06 20:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-06 14:27 [PATCH] Fix e1000e with Intel 82572EI that has no hardware timestamp support Koehrer Mathias (ETAS/ESW5)
2014-08-06 14:30 ` Sergei Shtylyov
2014-08-06 15:09   ` Henrique de Moraes Holschuh
2014-08-06 15:21     ` Alexander Duyck
2014-08-06 15:26       ` Alexander Duyck
     [not found]         ` <CAPDOMVgHmQeqOGj1MegRa=gusGXMn5t7cwCNnutpc1_q_fzyYg@mail.gmail.com>
2014-08-06 20:19           ` Alexander Duyck [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-08-06 14:32 Koehrer Mathias (ETAS/ESW5)
2014-08-06 19:17 ` Richard Cochran
     [not found]   ` <CAPDOMVjYkfM49E9DM0=SDDRncLQbXxR8NQE9SrsW++YycMGU5w@mail.gmail.com>
2014-08-06 19:32     ` Richard Cochran
     [not found]       ` <CAPDOMViFCifeUoOgExuG7Q6_ObGj20g59siyMxWeKN=Zr2Kbdg@mail.gmail.com>
2014-08-06 19:54         ` Richard Cochran
2014-08-07  6:10           ` Koehrer Mathias (ETAS/ESW5)
2014-08-07  6:20             ` Jeff Kirsher
2014-08-06 13:56 Koehrer Mathias (ETAS/ESW5)
2014-08-06 13:56 ` Koehrer Mathias (ETAS/ESW5)
2014-08-06 14:05 ` Sergei Shtylyov

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=53E28DD9.6060503@intel.com \
    --to=alexander.h.duyck@intel.com \
    --cc=hmh@hmh.eng.br \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathias.koehrer@etas.com \
    --cc=netdev@vger.kernel.org \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=xerofoify@gmail.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.