All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: Murali Karicheri <m-karicheri2@ti.com>,
	David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: skb allocation from interrupt handler?
Date: Wed, 9 Aug 2017 16:31:26 -0700	[thread overview]
Message-ID: <20170809163126.207392df@xeon-e3> (raw)
In-Reply-To: <20170809222919.GA4101@electric-eye.fr.zoreil.com>

On Thu, 10 Aug 2017 00:29:19 +0200
Francois Romieu <romieu@fr.zoreil.com> wrote:

> Murali Karicheri <m-karicheri2@ti.com> :
> [...]
> > The internal memory or FIFO can store only up to 3 MTU sized packets. So that has to
> > be processed before PRU gets another packets to send to CPU. So per above, 
> > it is not ideal to run NAPI for this scenario, right? Also for NetCP we use
> > about 128 descriptors with MTU size buffers to handle 1Gbps Ethernet link.
> > Based on that roughly we would need at least 10-12 buffers in the FIFO.
> > 
> > Currently we have a NAPI implementation in use that gives throughput of 95Mbps for
> > MTU sized packets, but our UDP iperf tests shows less than 1% packet loss for an
> > offered traffic of 95Mbps with MTU sized packets.  This is not good for industrial
> > network using HSR/PRP protocol for network redundancy. We need to have zero packet
> > loss for MTU sized packets at 95Mbps throughput. That is the problem description.  
> 
> Imvho you should instrument the kernel to figure where the excess latency that
> prevents NAPI processing to take place within 125 us of physical packet reception
> comes from.
> 
> > As an experiment, I have moved the packet processing to irq handler to see if we 
> > can take advantage of CPU cycle to processing the packet instead of NAPI
> > and to check if the firmware encounters buffer overflow. The result is positive 
> > with no buffer overflow seen at the firmware and no packet loss in the iperf test.
> > But we want to do more testing as an experiment and ran into a uart console locks
> > up after running traffic for about 2 minutes. So I tried enabling the DEBUG HACK 
> > options to get some clue on what is happening and ran into the trace I shared 
> > earlier. So what function can I use to allocate SKB from interrupt handler ?  
> 
> Is your design also so tight on memory that you can't even refill your own
> software skb pool from some non-irq context then only swap buffers in the
> irq handler ?
> 

The current best practice in network drivers is to receive into
an allocated page, then create skb meta data with build_skb() in the NAPI poll
routine.

      reply	other threads:[~2017-08-09 23:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-08 22:17 skb allocation from interrupt handler? Murali Karicheri
2017-08-08 22:29 ` Matteo Croce
2017-08-09 16:04   ` Murali Karicheri
2017-08-08 23:00 ` David Miller
2017-08-09 16:36   ` Murali Karicheri
2017-08-09 22:29     ` Francois Romieu
2017-08-09 23:31       ` Stephen Hemminger [this message]

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=20170809163126.207392df@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=davem@davemloft.net \
    --cc=m-karicheri2@ti.com \
    --cc=netdev@vger.kernel.org \
    --cc=romieu@fr.zoreil.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.