IPMI SOL performance

[Kun Yi]

SOL performance issue aside, there is also an IPMI command for selecting
the boot device. Is that command currently supported in the client in any
way? That might be a more reliable solution than relying on console alone.


On Mon, Mar 19, 2018 at 12:21 PM Emily Shaffer <emilyshaffer at google.com>
wrote:

>
>
> On Mon, Mar 19, 2018 at 12:04 PM Tom Joseph <tomjose at linux.vnet.ibm.com>
> wrote:
>
>>
>>
>> On Tuesday 20 March 2018 12:17 AM, Emily Shaffer wrote:
>>
>>
>>
>> On Mon, Mar 19, 2018 at 9:27 AM Stewart Smith <stewart at linux.vnet.ibm.com>
>> wrote:
>>
>>> Emily Shaffer <emilyshaffer at google.com> writes:
>>> >> Is it a possibility to just increase the petitboot timeout? Do you
>>> have an
>>> > idea of how much we are missing it by?
>>>
>>> Worst case (may be different currently due to improvements in ipmi
>>> stack) was about 10-15 minutes.
>>
>> Yikes.
>>
>>>
>>
>>
>>> We have different issues on the SSH console though, we can end up
>>> dropping chunks of console output under load (BMC CPU load or high
>>> console usage).
>>>
>>> I think Jeremy can relive the trauma of heading into the TTY layer, but
>>> I wonder if the solution here has something to do with having a
>>> end-to-end flow control story.
>>>
>>> --
>>> Stewart Smith
>>> OPAL Architect, IBM.
>>>
>>>
>> I was looking in the spec and I saw that the packet length for SOL is
>> configurable in the session header, but I didn't find the layout for the
>> header.  It's definitely not configurable past 255B?
>>
>>
>> Even though character data field is a variable length field, the accepted
>> character count in the SOL payload is a single byte. It is based on the
>> accepted character count that console acknowledges to BMC and offset is
>> changed. That is the 255 character limitation mentioned.
>>
>>
>> It really doesn't sound like IPMI is well-suited to this task.  Tom, can
>> you post a proposal for the OEM command you'd like to see, or if you've
>> tried one internally?
>>
>> I haven't tried this option, the OEM option is to bump the accepted
>> character count field. It will need changes on the clients (like ipmitool).
>>
>> I don't know that this is the right approach, as it would break anybody
> trying to use OpenBMC with their own copy of ipmitool.  I'd rather see an
> entirely separate OEM command that we can tailor to our needs (for example,
> if we are expecting ACK/NACK with SOL in the form of another IPMI command,
> does it make more sense to just use TCP in an OEM command instead), either
> leaving the slow per-spec approach up as best-effort, or adding some
> warning to anyone trying to use it that we've added an improved OEM
> command.  Just my two cents...
>
>


-- 
Regards,
Kun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180319/13c8dcb4/attachment.html>