<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Calibri" size="2"><span style="font-size:10pt;">
<div style="padding-right:5pt;padding-left:5pt;"><font color="blue">[AMD Official Use Only - AMD Internal Distribution Only]<br>

</font></div>
<div style="margin-top:5pt;"><font face="Times New Roman" size="3"><span style="font-size:12pt;"><br>

</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;"><snipped></span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> ></span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > For the naming, would "rte_get_next_sibling_core" (or lcore if you</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > prefer) be a clearer name than just adding "ex" on to the end of the</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > existing function?</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> ></span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > Looking logically, I'm not sure about the BOOST_ENABLED and</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > BOOST_DISABLED flags you propose - in a system with multiple possible</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > standard and boost frequencies what would those correspond to? What's</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > also missing is a define for getting actual NUMA siblings i.e. those</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > sharing common memory but not an L3 or anything else.</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> ></span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > My suggestion would be to have the function take just an integer-type e.g.</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > uint16_t parameter which defines the memory/cache hierarchy level to</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > use, 0 being lowest, 1 next, and so on. Different systems may have</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > different numbers of cache levels so lets just make it a zero-based</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > index of levels, rather than giving explicit defines (except for</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > memory which should probably always be last). The zero-level will be for</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> "closest neighbour"</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > whatever that happens to be, with as many levels as is necessary to</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > express the topology, e.g. without SMT, but with 3 cache levels, level</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > 0 would be an L2 neighbour, level 1 an L3 neighbour. If the L3 was</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > split within a memory NUMA node, then level 2 would give the NUMA</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> > siblings. We'd just need an API to return the max number of levels along with</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> the iterator.</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> </span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">> Sounds like a neat idea to me.</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;"> </span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">Hi Konstantin, I have tried my best to address to Bruce comment. Let me try to recap</span></font></div>
<ol style="margin:0;padding-left:36pt;list-style-type:decimal;">
<font face="Calibri" size="2"><span style="font-size:11pt;">
<li>we want vendor agnostic API which allows end users to get list of lcores</li><li>this can be based on L1(SMT), L2, L3, NUMA, TURBO (as of now)</li><li>instead of creating multiple different API, we would like to add 1 API `rte_get_next_lcore_extnd` which can be controlled with `flags`</li><li>flag can be single or combination (like L3|TURBO_ENABLED or NUMA|TURBO_ENABLED).</li><li>As per my current idea, we can expand ease of use via MACRO and not API.</li></span></font>
</ol>
<div><font face="Calibri" size="2"><span style="font-size:11pt;"> </span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">I hope this justifies why we should have 1 exntended API and wrap things with Macro?</span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;">May I setup or add to tech discussion call with Mattias and Honappa too?</span></font></div>
</span></font>
</body>
</html>