From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 3/3] net: hisilicon: new hip04 ethernet driver
Date: Wed, 10 Dec 2014 10:35:20 +0100 [thread overview]
Message-ID: <2331317.LV3gPP3odb@wuerfel> (raw)
In-Reply-To: <5487EC09.8090907@huawei.com>
On Wednesday 10 December 2014 14:45:29 Ding Tianhong wrote:
>
> Miss this code, I think the best way is skb_orphan(skb), just like the cxgb3 drivers, some hardware
> didn't use the tx inq to free dmad Tx packages.
The problem with skb_orphan is that you are telling the network stack that
the packet is now out of its reach and it will no longer be able to take
queued packets into account. This can work as long as you are guaranteed
to never fill up the tx queue and assume that the network link is always
faster than your CPUs, but then you have to do additional steps, at least:
- turn off flow control (pause frames)
- disable half-duplex, 10mbit and 100mbit connections
- remove the byte queue limit code from the driver
- never call netif_stop_queue or return NETDEV_TX_BUSY from the tx
function, but instead drop the oldest packets from the tx queue
to make room, and rely on higher-level protocols (TCP) to throttle
the output
- for best throughput, don't bother looking at the status of the tx
queue until it has filled up, then clean up all transmitted packets
(if any) but at least enough so you can continue sending a bit longer.
The above can work because you know the device is only used in one SoC
that has a relatively slow CPU. I would describe it as "we don't know
how much data we can send, but in doubt we send more and do our best
to make that case as rare as possible". It's also management friendly
because you can reach higher-than-gigabit transmit rates this way
if you ignore the packet loss ;-). The price for this is that you
eventually have to retransmit packets that get dropped.
The alternative to this is to keep all the features of the network
stack in place and to keep retrying the tx cleanup in some way so
you don't have to orphan or drop any skbs. This could be as easy as
- drop the skb_orphan() call
- make hip04_tx_reclaim() return an error if the queue is still full
- do not call napi_complete or turn on the rx irq if hip04_tx_reclaim
failed
Arnd
next prev parent reply other threads:[~2014-12-10 9:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-19 1:12 [PATCH v8 0/3] add hisilicon hip04 ethernet driver Zhangfei Gao
2014-04-19 1:12 ` [PATCH v8 1/3] Documentation: add Device tree bindings for Hisilicon hip04 ethernet Zhangfei Gao
2014-04-19 1:12 ` [PATCH v8 2/3] net: hisilicon: new hip04 MDIO driver Zhangfei Gao
2014-04-21 17:58 ` Sergei Shtylyov
2014-04-21 18:03 ` Florian Fainelli
2014-04-21 18:21 ` Sergei Shtylyov
2014-04-22 6:03 ` zhangfei
2014-04-22 8:22 ` Arnd Bergmann
2014-04-22 14:16 ` zhangfei
2014-04-22 14:30 ` Arnd Bergmann
2014-04-22 14:58 ` zhangfei
2014-04-24 12:28 ` Arnd Bergmann
2014-04-24 13:00 ` zhangfei
2014-04-19 1:13 ` [PATCH v8 3/3] net: hisilicon: new hip04 ethernet driver Zhangfei Gao
2014-12-07 0:42 ` Alexander Graf
2014-12-07 3:28 ` Ding Tianhong
2014-12-07 9:49 ` Alexander Graf
2014-12-07 20:09 ` Arnd Bergmann
2014-12-08 1:48 ` Ding Tianhong
2014-12-10 3:51 ` Ding Tianhong
2014-12-10 6:45 ` Ding Tianhong
2014-12-10 9:35 ` Arnd Bergmann [this message]
2014-12-10 16:07 ` David Miller
2014-12-10 16:36 ` Arnd Bergmann
2014-12-10 17:02 ` David Miller
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=2331317.LV3gPP3odb@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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