From: Jeremy Kerr <jk@ozlabs.org>
To: Patrick Williams <patrick@stwcx.xyz>
Cc: "Khetan, Sharad" <sharad.khetan@intel.com>,
Deepak Kodihalli <dkodihal@linux.vnet.ibm.com>,
Andrew Jeffery <andrew@aj.id.au>,
Vijay Khemka <vijaykhemka@fb.com>, rgrs <rgrs@protonmail.com>,
"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
"Bhat, Sumanth" <sumanth.bhat@intel.com>,
"Winiarska, Iwona" <iwona.winiarska@intel.com>
Subject: Re: MCTP over PCI on AST2500
Date: Wed, 15 Jan 2020 21:51:38 +0800 [thread overview]
Message-ID: <ade63a1fda67cd8df1a2ba0638b1015878a0ac80.camel@ozlabs.org> (raw)
In-Reply-To: <20200114174532.GB3512@patrickw3-mbp.dhcp.thefacebook.com>
Hi Patrick,
> > Just a suggestion - you probably don't want to be passing MCTP
> > messages over dbus - this is something we learnt from the IPMI
> > implementation.
>
> Is there a pointer to this "lesson learned" or the issues surrounding
> it? It seems like the btbridge is still using dbus, so I assume
> host-ipmid is as well.
>
> https://github.com/openbmc/btbridge/blob/master/btbridged.c#L47
>
> I'm curious to understand what the issues were/are.
No, nothing that anyone had specifically documented. I recall there
were concerns with shuffling larger amounts of data over dbus,
particularly for things like firmware update over IPMI. Because we're
using a dbus signal for incoming messages, we could potentially be
writing a lot of data to multiple processes - and more than necessary
if those processes haven't set up their dbus matches correctly.
I don't think there's enough concern to change existing code over for,
more just a consideration for future designs, of which this is one.
Cheers,
Jeremy
next prev parent reply other threads:[~2020-01-15 13:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-20 5:26 MCTP over PCI on AST2500 rgrs
2019-11-20 6:54 ` Vijay Khemka
2019-11-20 6:59 ` Khetan, Sharad
2019-11-22 0:38 ` Andrew Jeffery
2019-12-21 0:15 ` Khetan, Sharad
2020-01-09 1:57 ` Andrew Jeffery
2020-01-09 18:17 ` Vijay Khemka
2020-01-09 20:45 ` Richard Hanley
2020-01-10 1:29 ` Andrew Jeffery
2020-01-10 0:30 ` Andrew Jeffery
2020-01-13 16:53 ` Khetan, Sharad
2020-01-13 18:54 ` Deepak Kodihalli
2020-01-14 5:54 ` Khetan, Sharad
2020-01-14 6:20 ` Jeremy Kerr
2020-01-14 6:39 ` Khetan, Sharad
2020-01-14 8:10 ` Deepak Kodihalli
2020-01-14 15:54 ` Thomaiyar, Richard Marian
2020-01-14 17:45 ` Patrick Williams
2020-01-15 13:51 ` Jeremy Kerr [this message]
2020-01-15 14:16 ` Patrick Williams
2020-01-14 8:54 ` rgrs
2020-01-13 23:22 ` Andrew Jeffery
2020-01-10 3:40 ` Michael Richardson
2020-01-10 5:05 ` Andrew Jeffery
2020-01-10 15:38 ` Michael Richardson
2020-01-12 23:38 ` Andrew Jeffery
2020-01-13 17:09 ` Michael Richardson
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=ade63a1fda67cd8df1a2ba0638b1015878a0ac80.camel@ozlabs.org \
--to=jk@ozlabs.org \
--cc=andrew@aj.id.au \
--cc=dkodihal@linux.vnet.ibm.com \
--cc=iwona.winiarska@intel.com \
--cc=openbmc@lists.ozlabs.org \
--cc=patrick@stwcx.xyz \
--cc=rgrs@protonmail.com \
--cc=sharad.khetan@intel.com \
--cc=sumanth.bhat@intel.com \
--cc=vijaykhemka@fb.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.