Re: warning of pending commit attempt.

Kris Kennaway wrote:
> Julian Elischer wrote:
>> Kris Kennaway wrote:
>>> Julian Elischer wrote:
>>>> Andre Oppermann wrote:
>>>>> Brooks Davis wrote:
>>>>>> On Mon, Feb 25, 2008 at 08:44:56PM -0800, Julian Elischer wrote:
>>>>>>
>>>>>>> At some stage in the next few weeks I will be trying to commit
>>>>>>> Marco Zec's vimage code to -current. (only 'trying' not
>>>>>>> for technical reasons, but political).
>>>>> ...
>>>>>>> Why now?
>>>>>>>  The code is in a shape where teh compiled out version of hte 
>>>>>>> system is stable. In the compiled in version, it is functional
>>>>>>> enough to provide nearly all of what people want. It needs people 
>>>>>>> with other interests to adapt it to their purposes and use it so 
>>>>>>> that it can become a solid product for future releases.
>>>>>>
>>>>>> The website has a snapshot with a date over a month old and many
>>>>>> comments about unstable interfaces.  I've seen zero reports of
>>>>>> substantial testing...
>>>>>
>>>>> What about locking and SMP scalability?  Any new choke points?
>>>>
>>>> not that I've seen.
>>>
>>> That's a less than resounding endorsement :)
>>
>> do the 10Gb ethernet adapters have any major problems?
>> are you willing to answer "no"?
>> should we then rip them from the tree?
> 
> Those are small, isolated components, so hardly the same thing as a 
> major architectural change that touches every part of the protocol stack.
> 
> But if someone came along and said "I am going to replace the 10ge 
> drivers, but I dunno how well they perform" I'd say precisely the same 
> thing.
> 
> Presumably someone (if not you, then Marko) has enough of a grasp of the 
> architectural changes being proposed to comment about what changes (if 
> any) were made to synchronisation models, and whether there are new 
> sources of performance overhead introduced.
> 
> That person can answer Andre's question.

no changes were made to the general synchronisatrion strategies.
Each instance of the stack runs independently and has the same
locks as the current stack. It's just that there are multiple of them.
they never cross paths (except to get mbufs) and that works with 
multiple clients so doesn't need to be changed. The only elements that 
cross over are netgraph and some virtual interfaces.

> 
> Kris