<br><tt><font size=2>Dave Hansen <haveblue@us.ibm.com> wrote on 15.02.2008
17:55:38:</font></tt>
<br>
<br><tt><font size=2>> I've been thinking about that, and I don't think
you really *need* to</font></tt>
<br><tt><font size=2>> keep a comprehensive map like that. </font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> When the memory is in a particular configuration
(range of memory</font></tt>
<br><tt><font size=2>> present along with unique set of holes) you get
a unique ehea_bmap</font></tt>
<br><tt><font size=2>> configuration. That layout is completely
predictable.</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> So, if at any time you want to figure out what
the ehea_bmap address for</font></tt>
<br><tt><font size=2>> a particular *Linux* virtual address is, you
just need to pretend that</font></tt>
<br><tt><font size=2>> you're creating the entire ehea_bmap, use the
same algorithm and figure</font></tt>
<br><tt><font size=2>> out host you would have placed things, and use
that result.</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> Now, that's going to be a slow, crappy linear
search (but maybe not as</font></tt>
<br><tt><font size=2>> slow as recreating the silly thing). So,
you might eventually run into</font></tt>
<br><tt><font size=2>> some scalability problems with a lot of packets
going around. But, I'd</font></tt>
<br><tt><font size=2>> be curious if you do in practice.</font></tt>
<br>
<br><tt><font size=2>Up to 14 addresses translation per packet (sg_list)
might be required on the</font></tt>
<br><tt><font size=2>transmit side. On receive side it is only 1. Most
packets require only very few</font></tt>
<br><tt><font size=2>translations (1 or sometimes more) translations.
However, with more then 700.000 </font></tt>
<br><tt><font size=2>packets per second this approach does not seem reasonable
from performance</font></tt>
<br><tt><font size=2>perspective when memory is fragmented as you described.</font></tt>
<br>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> The other idea is that you create a mapping that
is precisely 1:1 with</font></tt>
<br><tt><font size=2>> kernel memory. Let's say you have two sections
present, 0 and 100. You</font></tt>
<br><tt><font size=2>> have a high_section_index of 100, and you vmalloc()
a 100 entry array.</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> You need to create a *CONTIGUOUS* ehea map? Create
one like this:</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> EHEA_VADDR->Linux Section</font></tt>
<br><tt><font size=2>> 0->0</font></tt>
<br><tt><font size=2>> 1->0</font></tt>
<br><tt><font size=2>> 2->0</font></tt>
<br><tt><font size=2>> 3->0</font></tt>
<br><tt><font size=2>> ...</font></tt>
<br><tt><font size=2>> 100->100</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> It's contiguous. Each area points to a
valid Linux memory address.</font></tt>
<br><tt><font size=2>> It's also discernable in O(1) to what EHEA address
a given Linux address</font></tt>
<br><tt><font size=2>> is mapped. You just have a couple of duplicate
entries. </font></tt>
<br>
<br><tt><font size=2>This has a serious issues with constraint I mentions
in the previous mail: </font></tt>
<br><tt><font size=2>"- MRs can have a maximum size of the memory
available under linux"</font></tt>
<br>
<br><tt><font size=2>The requirement is not met that the memory region
must not be </font></tt>
<br><tt><font size=2>larger then the available memory for that partition.
The "create MR" H_CALL</font></tt>
<br><tt><font size=2>will fails (we tried this and discussed with FW development)</font></tt>
<br>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Jan-Bernd & Christoph</font></tt>