From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Stephane Le Provost <stephane.leprovost@mediatek.com>,
Pedro Tsai <pedro.tsai@mediatek.com>,
Andrew Perepech <andrew.perepech@mediatek.com>,
Rob Herring <robh+dt@kernel.org>,
"David S . Miller" <davem@davemloft.net>,
Matthias Brugger <matthias.bgg@gmail.com>,
John Crispin <john@phrozen.org>,
Sean Wang <sean.wang@mediatek.com>,
Mark Lee <Mark-MC.Lee@mediatek.com>,
Jakub Kicinski <kuba@kernel.org>,
Fabien Parent <fparent@baylibre.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Edwin Peer <edwin.peer@broadcom.com>,
DTML <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Networking <netdev@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"moderated list:ARM/Mediatek SoC..."
<linux-mediatek@lists.infradead.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [PATCH v4 06/11] net: ethernet: mtk-eth-mac: new driver
Date: Fri, 22 May 2020 09:44:33 +0200 [thread overview]
Message-ID: <CAMRc=MfVkbDSfEV71SD57dpYthdx5epD0FOvjRx8qQGT+SgsTQ@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a1nhPj6kRhwyXzDK3BGbh66XG6Fmp44QuM1NhFPPBTtPQ@mail.gmail.com>
śr., 20 maj 2020 o 23:23 Arnd Bergmann <arnd@arndb.de> napisał(a):
>
> On Wed, May 20, 2020 at 7:35 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > śr., 20 maj 2020 o 16:37 Arnd Bergmann <arnd@arndb.de> napisał(a):
>
> > > I just noticed how the naming of NET_MEDIATEK_MAC and NET_MEDIATEK_SOC
> > > for two different drivers doing the same thing is really confusing.
> > >
> > > Maybe someone can come up with a better name, such as one
> > > based on the soc it first showed up in.
> > >
> >
> > This has been discussed under one of the previous submissions.
> > MediaTek wants to use this IP on future designs as well and it's
> > already used on multiple SoCs so they want the name to be generic. I
> > also argued that this is a driver strongly tied to a specific
> > platform(s) so if someone wants to compile it - they probably know
> > what they're doing.
> >
> > That being said: I verified with MediaTek and the name of the IP I can
> > use is "star" so they proposed "mtk-star-eth". I would personally
> > maybe go with "mtk-star-mac". How about those two?
>
> Both seem fine to me. If this was previously discussed, I don't want
> do further bike-shedding and I'd trust you to pick a sensible name
> based on the earlier discussions.
>
> > > + /* One of the counters reached 0x8000000 - update stats and
> > > > + * reset all counters.
> > > > + */
> > > > + if (unlikely(status & MTK_MAC_REG_INT_STS_MIB_CNT_TH)) {
> > > > + mtk_mac_intr_disable_stats(priv);
> > > > + schedule_work(&priv->stats_work);
> > > > + }
> > > > + befor
> > > > + mtk_mac_intr_ack_all(priv);
> > >
> > > The ack here needs to be dropped, otherwise you can get further
> > > interrupts before the bottom half has had a chance to run.
> > >
> >
> > My thinking was this: if I mask the relevant interrupt (TX/RX
> > complete) and ack it right away, the status bit will be asserted on
> > the next packet received/sent but the process won't get interrupted
> > and when I unmask it, it will fire right away and I won't have to
> > recheck the status register. I noticed that if I ack it at the end of
> > napi poll callback, I end up missing certain TX complete interrupts
> > and end up seeing a lot of retransmissions even if I reread the status
> > register. I'm not yet sure where this race happens.
>
> Right, I see. If you just ack at the end of the poll function, you need
> to check the rings again to ensure you did not miss an interrupt
> between checking observing both rings to be empty and the irq-ack.
>
> I suspect it's still cheaper to check the two rings with an uncached
> read from memory than to to do the read-modify-write on the mmio,
> but you'd have to measure that to be sure.
>
Unfortunately the PHY on the board I have is 100Mbps which is the
limiting factor in benchmarking this driver. :(
If you're fine with this - I'd like to fix the minor issues you
pointed out and stick with the current approach for now. We can always
fix the implementation in the future once a board with a Gigabit PHY
is out. Most ethernet drivers don't use such fine-grained interrupt
control anyway. I expect the performance differences to be miniscule
really.
Bart
next prev parent reply other threads:[~2020-05-22 7:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-20 11:25 [PATCH v4 00/11] mediatek: add support for MediaTek Ethernet MAC Bartosz Golaszewski
2020-05-20 11:25 ` [PATCH v4 01/11] dt-bindings: convert the binding document for mediatek PERICFG to yaml Bartosz Golaszewski
2020-05-20 11:25 ` [PATCH v4 02/11] dt-bindings: add new compatible to mediatek,pericfg Bartosz Golaszewski
2020-05-20 11:25 ` [PATCH v4 03/11] dt-bindings: net: add a binding document for MediaTek Ethernet MAC Bartosz Golaszewski
2020-05-20 11:25 ` [PATCH v4 04/11] net: ethernet: mediatek: rename Kconfig prompt Bartosz Golaszewski
2020-05-20 11:25 ` [PATCH v4 05/11] net: ethernet: mediatek: remove unnecessary spaces from Makefile Bartosz Golaszewski
2020-05-20 11:25 ` [PATCH v4 06/11] net: ethernet: mtk-eth-mac: new driver Bartosz Golaszewski
2020-05-20 14:37 ` Arnd Bergmann
2020-05-20 17:34 ` Bartosz Golaszewski
2020-05-20 21:22 ` Arnd Bergmann
2020-05-22 7:44 ` Bartosz Golaszewski [this message]
2020-05-22 7:49 ` Arnd Bergmann
2020-05-20 11:25 ` [PATCH v4 07/11] ARM64: dts: mediatek: add pericfg syscon to mt8516.dtsi Bartosz Golaszewski
2020-05-20 11:25 ` [PATCH v4 08/11] ARM64: dts: mediatek: add the ethernet node " Bartosz Golaszewski
2020-05-20 11:25 ` [PATCH v4 09/11] ARM64: dts: mediatek: add an alias for ethernet0 for pumpkin boards Bartosz Golaszewski
2020-05-20 11:25 ` [PATCH v4 10/11] ARM64: dts: mediatek: add ethernet pins " Bartosz Golaszewski
2020-05-20 11:25 ` [PATCH v4 11/11] ARM64: dts: mediatek: enable ethernet on " Bartosz Golaszewski
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='CAMRc=MfVkbDSfEV71SD57dpYthdx5epD0FOvjRx8qQGT+SgsTQ@mail.gmail.com' \
--to=brgl@bgdev.pl \
--cc=Mark-MC.Lee@mediatek.com \
--cc=andrew.perepech@mediatek.com \
--cc=arnd@arndb.de \
--cc=bgolaszewski@baylibre.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edwin.peer@broadcom.com \
--cc=fparent@baylibre.com \
--cc=hkallweit1@gmail.com \
--cc=john@phrozen.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pedro.tsai@mediatek.com \
--cc=robh+dt@kernel.org \
--cc=sean.wang@mediatek.com \
--cc=stephane.leprovost@mediatek.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).