SCMI protocol for interconnect scaling

SCMI protocol for interconnect scaling

[Georgi Djakov]

Hi all,

I am recently getting questions about hooking the interconnect framework
to SCMI, so i am starting a discussion on this problem and see who might
be interested in it.

The SCMI spec contains various protocols like the "Performance domain 
management protocol". But none of the protocols mentioned in the current
spec (3.0) seem to fit well into the concept we are using to scale
interconnect bandwidth in Linux. I see that people are working in this
area and there is already some support for clocks, resets etc. I am
wondering what would be the right approach to support also interconnect
bus scaling via SCMI.

The interconnect framework is part of the linux kernel and it's goal
is to manage the hardware and tune it to the most optimal power-
performance profile according to the aggregated bandwidth demand between
the various endpoints in the system (SoC). This is based on the requests
coming from consumer drivers.

As interconnects scaling does not map directly to any of the currently
available protocols in the SCMI spec, i am curious whether there is
work in progress on some other protocol that could support managing
resources based on path endpoints (instead of a single ID). The
interconnect framework doesn't populate every possible path, but
it exposes endpoints to client drivers and the path lookup is dynamic,
based on what the clients request. Maybe the SCMI host could also expose
all possible endpoints and let the guest request a path from the host,
based on those endpoints.

There are already suggestions to create vendor-specific SCMI protocols
for that, but i fear that we may end up with more than one protocol for
the same thing, so that's why it might be best to discuss it in public
and have a common solution that works for everyone.

Thanks,
Georgi

RE: SCMI protocol for interconnect scaling

[Souvik Chakravarty]

Thanks Georgi for initiating this.
Don’t have too much to add, just some initial thinking on my part below.

> From: Georgi Djakov <djakov@kernel.org>
> Sent: Thursday, October 21, 2021 12:06 PM
>
>
> Hi all,
>
> I am recently getting questions about hooking the interconnect framework to
> SCMI, so i am starting a discussion on this problem and see who might be
> interested in it.
>
> The SCMI spec contains various protocols like the "Performance domain
> management protocol". But none of the protocols mentioned in the current
> spec (3.0) seem to fit well into the concept we are using to scale interconnect
> bandwidth in Linux. I see that people are working in this area and there is
> already some support for clocks, resets etc. I am wondering what would be the
> right approach to support also interconnect bus scaling via SCMI.

You are right - the current Performance Domain Mgmt. Protocol is not fit for
purpose for this requirement.

>
> The interconnect framework is part of the linux kernel and it's goal is to manage
> the hardware and tune it to the most optimal power- performance profile
> according to the aggregated bandwidth demand between the various endpoints
> in the system (SoC). This is based on the requests coming from consumer drivers.
>
> As interconnects scaling does not map directly to any of the currently available
> protocols in the SCMI spec, i am curious whether there is work in progress on
> some other protocol that could support managing resources based on path
> endpoints (instead of a single ID). The interconnect framework doesn't populate
> every possible path, but it exposes endpoints to client drivers and the path
> lookup is dynamic, based on what the clients request. Maybe the SCMI host
> could also expose all possible endpoints and let the guest request a path from
> the host, based on those endpoints.
>
> There are already suggestions to create vendor-specific SCMI protocols for that,
> but i fear that we may end up with more than one protocol for the same thing,
> so that's why it might be best to discuss it in public and have a common solution
> that works for everyone.

+1. If there is a common requirement to be found that is always the best. Vendor specific
protocols might end up with extensibility issues once a similar protocol gets
supported in a future version of the specification.

Regards,
Souvik

>
> Thanks,
> Georgi
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: SCMI protocol for interconnect scaling

[Georgi Djakov]

On 25.10.21 17:55, Souvik Chakravarty wrote:
> Thanks Georgi for initiating this.
> Don’t have too much to add, just some initial thinking on my part below.
>
>> From: Georgi Djakov <djakov@kernel.org>
>> Sent: Thursday, October 21, 2021 12:06 PM
>>
>>
>> Hi all,
>>
>> I am recently getting questions about hooking the interconnect framework to
>> SCMI, so i am starting a discussion on this problem and see who might be
>> interested in it.
>>
>> The SCMI spec contains various protocols like the "Performance domain
>> management protocol". But none of the protocols mentioned in the current
>> spec (3.0) seem to fit well into the concept we are using to scale interconnect
>> bandwidth in Linux. I see that people are working in this area and there is
>> already some support for clocks, resets etc. I am wondering what would be the
>> right approach to support also interconnect bus scaling via SCMI.
> 
> You are right - the current Performance Domain Mgmt. Protocol is not fit for
> purpose for this requirement.
> 
>>
>> The interconnect framework is part of the linux kernel and it's goal is to manage
>> the hardware and tune it to the most optimal power- performance profile
>> according to the aggregated bandwidth demand between the various endpoints
>> in the system (SoC). This is based on the requests coming from consumer drivers.
>>
>> As interconnects scaling does not map directly to any of the currently available
>> protocols in the SCMI spec, i am curious whether there is work in progress on
>> some other protocol that could support managing resources based on path
>> endpoints (instead of a single ID). The interconnect framework doesn't populate
>> every possible path, but it exposes endpoints to client drivers and the path
>> lookup is dynamic, based on what the clients request. Maybe the SCMI host
>> could also expose all possible endpoints and let the guest request a path from
>> the host, based on those endpoints.
>>
>> There are already suggestions to create vendor-specific SCMI protocols for that,
>> but i fear that we may end up with more than one protocol for the same thing,
>> so that's why it might be best to discuss it in public and have a common solution
>> that works for everyone.
> 
> +1. If there is a common requirement to be found that is always the best. Vendor specific
> protocols might end up with extensibility issues once a similar protocol gets
> supported in a future version of the specification.

Thanks Souvik! Maybe we should try to implement a vendor protocol as
a starting point? I am adding more people who might be interested in
SCMI - folks that have interconnect drivers already merged or in the
process or doing that. The goal is to see who is interested in this
and to figure out a list of requirements for the new protocol.

Apologies to people not interested in ARM's System Control and 
Management Interface. Please ignore this email.

Thanks,
Georgi

Re: SCMI protocol for interconnect scaling

[Sudeep Holla]

On Mon, Nov 01, 2021 at 07:05:29PM +0200, Georgi Djakov wrote:
> 
> On 25.10.21 17:55, Souvik Chakravarty wrote:
> > Thanks Georgi for initiating this.
> > Don’t have too much to add, just some initial thinking on my part below.
> > 
> > > From: Georgi Djakov <djakov@kernel.org>
> > > Sent: Thursday, October 21, 2021 12:06 PM
> > > 
> > > 
> > > Hi all,
> > > 
> > > I am recently getting questions about hooking the interconnect framework to
> > > SCMI, so i am starting a discussion on this problem and see who might be
> > > interested in it.
> > > 
> > > The SCMI spec contains various protocols like the "Performance domain
> > > management protocol". But none of the protocols mentioned in the current
> > > spec (3.0) seem to fit well into the concept we are using to scale interconnect
> > > bandwidth in Linux. I see that people are working in this area and there is
> > > already some support for clocks, resets etc. I am wondering what would be the
> > > right approach to support also interconnect bus scaling via SCMI.
> > 
> > You are right - the current Performance Domain Mgmt. Protocol is not fit for
> > purpose for this requirement.
> > 
> > > 
> > > The interconnect framework is part of the linux kernel and it's goal is to manage
> > > the hardware and tune it to the most optimal power- performance profile
> > > according to the aggregated bandwidth demand between the various endpoints
> > > in the system (SoC). This is based on the requests coming from consumer drivers.
> > > 
> > > As interconnects scaling does not map directly to any of the currently available
> > > protocols in the SCMI spec, i am curious whether there is work in progress on
> > > some other protocol that could support managing resources based on path
> > > endpoints (instead of a single ID). The interconnect framework doesn't populate
> > > every possible path, but it exposes endpoints to client drivers and the path
> > > lookup is dynamic, based on what the clients request. Maybe the SCMI host
> > > could also expose all possible endpoints and let the guest request a path from
> > > the host, based on those endpoints.
> > > 
> > > There are already suggestions to create vendor-specific SCMI protocols for that,
> > > but i fear that we may end up with more than one protocol for the same thing,
> > > so that's why it might be best to discuss it in public and have a common solution
> > > that works for everyone.
> > 
> > +1. If there is a common requirement to be found that is always the best. Vendor specific
> > protocols might end up with extensibility issues once a similar protocol gets
> > supported in a future version of the specification.
> 
> Thanks Souvik! Maybe we should try to implement a vendor protocol as
> a starting point? I am adding more people who might be interested in
> SCMI - folks that have interconnect drivers already merged or in the
> process or doing that. The goal is to see who is interested in this
> and to figure out a list of requirements for the new protocol.

If we are merging any support for this via vendor protocol, I would like
it to support all those vendors with interconnect support merged upstream
using a single protocol rather than per-vendor protocol. i.e. if possible
talk with all those vendors before finalising the vendor protocol.

-- 
Regards,
Sudeep