LAS16-207: Bus scaling QoS

Bus Scaling QoSGeorgi Dja kov

ENGINEERS AND DEVICES

WORKING TOGETHER

Agenda

● Overview of On-Chip inte rconnects○ Cha llenges of SoC a rchitecture○ Evolution of On-Chip inte rconnects○ The Network-On-Chip concept

● Inte rconnects a nd the Linux kerne l○ Requirements○ Existing infra structure

● Solutions a nd future work

ENGINEERS AND DEVICESWORKING TOGETHER

Cha llenges of SoC Architecture

● High dema nd for integra ting more a nd more new fea tures (IP cores)● Multiple processors (CPUs, dedica ted GPU, video decoder, gra phics cores,

ha rdwa re a cce le ra tors, DSP, modem, ca mera , wifi, blue tooth, GPS e tc .)● Ma ny components ta lking to ea ch other● High speed, fa st tra nsfe rs, be tte r throughput e tc .● Multiple sources of tra ffic● Predicta bility (ma ny inte rrupts, concurrent tra nsfe rs, DDR utiliza tion)


Evolution of On-Chip inte rconnects

● Roles of the inte rconnects● Buses a nd crossba rs● More complex ha rdwa re● Sma ll footprint● Verifica tion becomes more difficult


TopologiesBus

Crossba r


TopologiesFully connected point to point ne twork


The Network-On-Chip concept


NoC a pproa ch benefits

● Sca la bility● Pa cke t communica tion● Sha red resources (links, memory)● Priority a nd QoS● Loa d ba la ncing● Power e ffic iency (short wires)


WORKING TOGETHER

Ne twork-On-Chip a nd Linux

● We wa nt to control the NoCs a nd use of a ll benefits● But how to do this in Linux… this ha s been not fully

a ddressed ye t● Out of the tree implementa tions● How does this fit in the Linux kerne l?


An exa mple use ca se

● Device X wa nts to rea ch device Y over a few NoCs● On wha t port is device X connected● Wha t a re the endpoints which device X ca n a ccess● Find the route to the destina tion endpoint● Ea ch node a ggrega tes the requests a nd se t QoS in ha rdwa re


An exa mple topology


Wha t do we need to solve this?

● Topology description of how the devices a nd buses a re inte rconnected● API for se tting constra ints on devices (source a nd destina tion pa ir)● Driver for the vendor specific ha rdwa re● QoS upda te triggers


Use existing Linux fra meworks a nd infra structure1/2

● The driver model● Device-tree● Consumer/provider ba sed API● Power ma na gement● Opera ting Performa nce Points● Devfreq


Use existing Linux fra meworks a nd infra structure2/2

● Dyna mic Volta ge a nd Frequency Sca ling● Runtime PM● Generic PM doma ins● PM QoS● Issues - la yering a nd a bstra ction


Consumer-provider model● Alrea dy used in ma ny kerne l subsystems● Model the inte rconnects a nd buses a s performa nce providers● The provider implementa tion is vendor specific a nd should provide the

following ca llba cks a s a minimum:○ init() - for initia lizing the ha rdwa re○ upda te () - for upda ting/se tting the constra ints

● The consumers use ge t/put API functions● Consumers se t constra ints on the pa th to a n endpoint.● The vendor-specific code upda tes a ll the nodes on the pa th


Device-tree1/2

● Describe inte rconnects be tween devices● Ca ll the NoC ha rdwa re a performa nce provider● Crea te a DT node for the NoC ha rdwa re controlle r

noc: noc@0120000 {compa tible = “vendor,noc";reg = <0x120000 0x10000>;#performa nce-ce lls = <1>;

}


Device-tree2/2

● Ca ll the consumer device a performa nce consumer● How a nd where the device is connected● Describe endpoints, flow direction, priorities e tc .● Use a ge t() API to c la im the link resource● Add link metrics?

consumer: device@0340000 {...

performa nce-port = <&noc 4>; /* connected to port 4 on NoC */performa nce-na mes = "usb", "displa y"; /* give a na me to ea ch link */performa nce-links = <&usb>, <&displa y>; /* pha ndles to device nodes */

}


Pe r device PM QoS

● Alrea dy exists in the kerne l but it is still not wide ly used● Used to store constra ints per ea ch device .● Add constra ints ba sed on source a nd destina tion device pa ir● Extend to support more tha n just min/ma x/sum


Runtime PM

● Currently power ma na gement is idle -ba sed ● The trigger is runtime_pm_put()● Add support for a ctive-ba sed power ma na gement● Use runtime_pm_get() a s a trigger for upda ting the bus/device performa nce


Generic PM doma ins

● Allow grouping of devices with simila r cha ra cte ristics● Currently used for ha rdwa re power doma ins● Support governors● Extend genpd to a llow a device to be in multiple PM doma ins


WORKING TOGETHER

The Solution?

● Performa nce fra mework or inte rconnect fra mework?● Consumer - provider ba sed model● Use device-tree to describe where a device is connected

a nd cla im the “links” a s resources● “Functiona l dependencies be tween devices” pa tchse t● Extend PM QoS● Use runtime_pm_get() a s trigger● Use Generic PM Doma ins for grouping devices?● Involve more people from the community a nd from

diffe rent vendors


Future work● The “Functiona l dependencies be tween devices” pa tchse t by Ra fa e l Wysocki

is pla nned for 4.10● Extend PM QoS with source a nd destina tion device pa irs?● Add support for devices in multiple PM doma ins?● “BoF: Linux Device Performa nce Fra mework” a t ELCE (11.Oct.2016 Berlin)

● Reminder: There will be a session for discussions a fte r lunch!

Thank You

LAS16-207: Bus scaling QoS

Technology

Transcript of LAS16-207: Bus scaling QoS