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

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>]

On 19.11.21 15:06, Jan Beulich wrote:
> On 19.11.2021 13:50, Oleksandr Andrushchenko wrote:
>> 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."
> FTAOD please don't forget to replace the <N> - I wasn't sure if it would
> be 2 or 3.
It seems we can't put the exact number as it depends on how many MSI/MSI-X
holes are there and that depends on an arbitrary device properties.
>   Also (nit) I don't think starting the 2nd sentence with "But
> ..." fits with the 1st sentence.
Sure, I will clean it up
>
> Jan
>
Thank you,
Oleksandr