[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55760CB0.1020503@cogentembedded.com>
Date: Tue, 09 Jun 2015 00:44:16 +0300
From: Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To: David Miller <davem@...emloft.net>
CC: robh+dt@...nel.org, pawel.moll@....com, mark.rutland@....com,
ijc+devicetree@...lion.org.uk, devicetree@...r.kernel.org,
galak@...eaurora.org, netdev@...r.kernel.org,
richardcochran@...il.com, linux-sh@...r.kernel.org,
mitsuhiro.kimura.kc@...esas.com
Subject: Re: [PATCH v5 1/2] Renesas Ethernet AVB driver proper
Hello.
On 06/04/2015 06:12 AM, David Miller wrote:
>> + /* Received network control queue */
>> + if (ris0 & RIS0_FRF1) {
>> + ravb_write(ndev, ~RIS0_FRF1, RIS0);
>> + /* Timestamp of network control packets that is based
>> + * on IEEE802.1AS, is used time synchronization of PTP.
>> + * It should not be handled by NAPI scheduling, because
>> + * it needs to be received as soon as possible.
>> + */
>> + ravb_rx(ndev, NULL, RAVB_NC);
>> + result = IRQ_HANDLED;
>> + }
> Nobody else makes this distinction, all packets should be processed
> via your NAPI path.
I see.
> When I see people conditionally invoking netif_rx()
> vs. netif_receive_skb() in their packet receive routine, like
> conditional locking, it's a big red flag.
> Furthermore, you should pass the NAPI context into ravb_rx() and use
I guess I should have one NAPI context per RX queue?
> it so that you can invoke napi_gro_receive() on all of the packets and
> therefore support GRO.
Hmm, I don't think I have a hardware support for generic RX offload...
I'm still unsure what it is anyway -- is it used for IP packet defragmentation?
WBR, Sergei
--
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