[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHrpEqQbaFK-j00X+SQ200Aur4BSnvUuM4nq5pYWVyd5XMWDrg@mail.gmail.com>
Date: Sun, 28 Apr 2013 18:05:00 +0800
From: Frank Li <lznuaa@...il.com>
To: Francois Romieu <romieu@...zoreil.com>
Cc: Robert Schwebel <r.schwebel@...gutronix.de>,
David Miller <davem@...emloft.net>,
Lucas Stach <l.stach@...gutronix.de>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"Frank.Li@...escale.com" <Frank.Li@...escale.com>,
Fabio Estevam <festevam@...il.com>,
Shawn Guo <shawn.guo@...aro.org>
Subject: Re: [PATCH resend 1/3] Revert "net: fec: fix missing napi_disable call"
2013/4/28 Francois Romieu <romieu@...zoreil.com>:
> Frank Li <lznuaa@...il.com> :
> [...]
>> This is lockless design if only one read and one write. It likes kfifo.
>>
>> Assume CPU1 run xmit. CPU2 run napi fec_enet_tx
>>
>> (1) if (fep->cur_tx == fep->dirty_tx)
>> (2) netif_stop_queue(ndev);
>>
>> if CPU2 update fep->dirty_tx before CPU1 run (1). the condition is false.
>> if CPU2 update fep->dirty_tx after (1) before (2), netif_stop_queue
>> will be called. There are not problem at this time even though queue
>> is not full here. queue is not empty for sure here. fec_enet_tx will
>> be called again when NAPI trigger by one frame finished transfer,
>> fec_enet_tx will wake up send queue.
>
> "before" and "after" may not work as expected between different CPU without
> explicit synchronization (or barrier). It won't oops but it would be careful
> to envision something like drivers/net/ethernet/broadcom/tg3.c::tg3_tx.
tg3_tx is safe method but need more lock.
But I think it is not related with this issue. I can change later.
>
> --
> Ueimor
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists