Re: [PATCH v4 06/11] vpci/header: handle p2m range sets per BAR

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>]

On 19.11.21 14:45, Jan Beulich wrote:
> On 19.11.2021 13:13, Oleksandr Andrushchenko wrote:
>> On 19.11.21 14:05, Jan Beulich wrote:
>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
>>>>
>>>> Instead of handling a single range set, that contains all the memory
>>>> regions of all the BARs and ROM, have them per BAR.
>>> Iirc Roger did indicate agreement with the spitting. May I nevertheless
>>> ask that for posterity you say a word here about the overhead, to make
>>> clear this was a conscious decision?
>> Sure, but could you please help me with that sentence to please your
>> eye? I mean that it was you seeing the overhead while I was not as
>> to implement the similar functionality as range sets do I still think we'll
>> duplicate range sets at the end of the day.
> "Note that rangesets were chosen here despite there being only up to
> <N> separate ranges in each set (typically just 1)." Albeit that's
> then still lacking a justification for the choice. Ease of
> implementation?
I guess yes. I'll put:

"Note that rangesets were chosen here despite there being only up to
<N> separate ranges in each set (typically just 1). But rangeset per BAR
was chosen for the ease of implementation and existing code re-usability."

>
> As to overhead - did you compare sizeof(struct rangeset) + N *
> sizeof(struct range) with just N * sizeof(unsigned long [2])?
I was not thinking about data memory sizes in the first place, but new code
introduced to handle that. And to be maintained.
>
> Jan
>
Thank you,
Oleksandr