From: andriy.shevchenko@linux.intel.com (Andy Shevchenko)
To: linux-arm-kernel@lists.infradead.org
Subject: [v2,1/1] ARM: orion5x: use mac_pton() helper
Date: Fri, 23 Feb 2018 18:57:39 +0200 [thread overview]
Message-ID: <1519405059.10722.120.camel@linux.intel.com> (raw)
In-Reply-To: <CAANYUdAzmJdwPH+kOJufG9NDVJVQr32qs-uWiy9Q5+moFCdBzw@mail.gmail.com>
On Fri, 2018-02-23 at 17:36 +0100, Stefan Hellermann wrote:
> 2018-02-23 16:51 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
> > > > Hi Andy
> > > >
> > > > Thanks for pointing this patch out.
> > > >
> > > > What is the advantage of doing to the strnlen()? As Stefan says,
> > > > the
> > > > code which follows will detect a short string, in that a NULL is
> > > > not
> > > > in [0-9a-f], nor a : .
> > >
> > > I'm not sure, but my understanding is that, the strchr() call in
> > > the
> > > original code or isxdigit() in the follow up change will trash a
> > > cache a
> > > bit. Besides that some of the users are (often?) supplying empty
> > > strings
> > > to convert from, and in this case makes sense to bail out fast.
> >
> > Is this function being called on a hot path? In the case which is
> > crashing, it is during early boot, and it gets called ~ 40 times, in
> > quick succession. The first call to isxdigit() will need to fetch
> > part
> > of the _ctype array into cache, but since the caller is only walking
> > memory, i hope it is still in cache for the next call to mac_pton().
> >
> > Andrew
>
> In my case mac_pton is not called on a hot path, the slow sata disks
> in the NAS dominate the boot time. For me code size matters, and on my
> device it's rarely called on a zero string. It's probably slower with
> the strnlen as without it. I think if there are users out there
> calling it in a hot path on a zero string, they should check the zero
> string themselves, this is not the common use case.
>
> Should I send a patch to netdev, can I get some Acked-by: ?
Not from me, sorry.
Alexey would be best person to give a such.
Please, Cc him.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2018-02-23 16:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-02 14:12 [PATCH v2 1/1] ARM: orion5x: use mac_pton() helper Andy Shevchenko
2015-10-13 11:27 ` Detlef Vollmann
2015-10-15 7:51 ` Gregory CLEMENT
2018-02-22 17:45 ` [v2,1/1] " Stefan Hellermann
2018-02-22 21:42 ` Andrew Lunn
2018-02-22 23:18 ` Stefan Hellermann
2018-02-22 23:34 ` Andrew Lunn
2018-02-23 10:09 ` Andy Shevchenko
2018-02-23 15:01 ` Andrew Lunn
2018-02-23 15:18 ` Andy Shevchenko
2018-02-23 15:51 ` Andrew Lunn
2018-02-23 16:36 ` Stefan Hellermann
2018-02-23 16:57 ` Andy Shevchenko [this message]
2018-02-23 17:23 ` Andrew Lunn
2018-02-23 18:20 ` Alexey Dobriyan
2018-02-23 20:17 ` [PATCH] net: Allow mac_pton() to work on non-NULL terminated strings Stefan Hellermann
2018-02-23 20:27 ` Andrew Lunn
2018-02-23 20:41 ` Alexey Dobriyan
2018-02-23 20:51 ` Andy Shevchenko
2018-02-26 18:37 ` 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=1519405059.10722.120.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--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;
as well as URLs for NNTP newsgroup(s).