From: Ed Tanous <edtanous@google.com>
To: Sunitha Harish <sunithaharish04@gmail.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>,
apparao.puli@linux.intel.com
Subject: Re: pthreads at bmcweb
Date: Tue, 19 Jan 2021 08:48:24 -0800 [thread overview]
Message-ID: <CAH2-KxB+vWmhYE3E7gsBeL+v-Skc5ds9Zxu9pqjUEZD6zwPkkA@mail.gmail.com> (raw)
In-Reply-To: <5181a536-a026-2f91-7335-f6a75b4694ab@gmail.com>
Another option might be something like c-ares, the description of which is:
c-ares... is intended for applications which need to perform DNS
queries without blocking, or need to perform multiple DNS queries in
parallel. The primary examples of such applications are servers which
communicate with multiple clients and programs with graphical user
interfaces.
Sounds like exactly our problem statement, so it might be worth a look
to see how much binary size it adds.
On Wed, Jan 6, 2021 at 12:02 AM Sunitha Harish
<sunithaharish04@gmail.com> wrote:
>
> Hi team,
>
> Reference commit https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/31735 :
>
> In order to handle the multiple push-style event subscribers, bmc needs to support the async resolution of the subscribers address. The async_resolve() API crashes if there is no thread support in the binary.
>
> I created a bmcweb binary patch by pulling this commit and including the pthread. This works fine for the use-cases, but increased the bmcweb binary size by 220KB.
>
> Ed's suggestion is not to use the pthreads, instead implement alternatives to do the same job, so that the binary size is kept minimum. He mentioned: "Considering that's a ~30% increase in binary size to support one line off code, and most systems are already at their binary size limit, no, that's not going to be acceptable. We can either patch boost to use this https://man7.org/linux/man-pages/man3/getaddrinfo_a.3.html or we could build our own resolver type that calls that underneath. This was based on a quick lookthrough of solutions in Google. I'm open to other ideas here".
>
> I am looking for the community views about the increased bmcweb binary size v/s having a custom implementation for asyc_resolve. Please share your views & ideas to get to the best solution.
>
>
> Thanks & regards,
> Sunitha
>
>
prev parent reply other threads:[~2021-01-19 18:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-06 8:02 pthreads at bmcweb Sunitha Harish
2021-01-06 18:12 ` Milton Miller II
2021-01-12 8:48 ` Sunitha Harish
2021-01-12 13:05 ` Patrick Williams
2021-01-18 9:49 ` Sunitha Harish
2021-01-19 16:48 ` Ed Tanous [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=CAH2-KxB+vWmhYE3E7gsBeL+v-Skc5ds9Zxu9pqjUEZD6zwPkkA@mail.gmail.com \
--to=edtanous@google.com \
--cc=apparao.puli@linux.intel.com \
--cc=openbmc@lists.ozlabs.org \
--cc=sunithaharish04@gmail.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.