[networking-discuss] Re: [brussels-dev] Re: [driver-discuss] Re: Brussels high-level design document

[Raymond LI - Sun Microsystems - Beijing China]

Garrett D'Amore wrote:
> sowmini.varadhan at sun.com wrote:
>> On (06/19/07 22:28), Raymond LI wrote:
>>  
>>>>> Garrett D'Amore wrote:
>>>>>            
>>>>>> Its because it doesn't need to be tunable.  The framework 
>>>>>> negotiates this feature with the drivers... it always enables the 
>>>>>> feature if the driver can support it.  There is never any reason 
>>>>>> to disable it.
>>>>>>
>>>>>>                 
>>>>> I had met questions from customer who complained his/her 
>>>>> application failed because all 0x0000 in TCP/IP's checksum field. 
>>>>> If we provide customer with better grained tuning over checksum 
>>>>> capability, he/she might be able to shoot or debug problems more 
>>>>> efficiently. And we could see most morden day drivers in 
>>>>> Windows/Linux have tx/rx checksum tunable respectively. I believe 
>>>>> at least for debug/workaround reasons, we should have this as an 
>>>>> option to customer.
>>>>>             
>>   :
>>  
>>>> I understand the occasional need to work around a bug in the field or
>>>> to help someone in services debug a customer issue.  Those are, I
>>>> think, the sorts of things where we ought to settle for hacks based on
>>>> /etc/system or mdb, rather than baking a profusion of cryptic driver
>>>> 'features' into a higher-level interface.
>>>>       
>>
>> One of the features that makes ndd very popular is that it allows
>> the setting of these debug/workaround knobs "on the fly", i.e., no 
>> reboot
>> required (as in /etc/system), and the driver can actually re-adjust
>> its state based on the setting requested (mdb cannot trigger state
>> re-adjustment in the driver by itself).
>>
>> Providing a way to do this on-the-fly debug/workaround setting was
>> one of the motivations for private properties. I agree that there is a
>> danger of abuse here, and maybe we can think of ways to control
>> the danger (by controlling documentation, perhaps?), but I see a benefit
>> in having private props for the short term, at least.
>>
>>   
>
> In this particular case, changing the checksum capability actually 
> requires renegotiation with IP.  I'm not sure whether IP is equipped 
> to deal with that or not.  (I think the ability may have been added.)
>
> In any case, this is *debug*, not normal usage, and should never be 
> needed if the hardware and drivers are working properly.  (I.e. if 
> they aren't suffering from bugs.)  An mdb or /etc/system tunable is 
> fine here... it may require the customer to unplumb/replumb the 
> interface, but, again, we do not expect this to be used unless our 
> software/hardware is somehow buggy.  Its far better that we make sure 
> the checksum support is bug free than that we give customers some knob 
> to control it, IMO.
>
I agree that this is used mostly as "debug" options. We are trying to 
keep the driver/hw bug free of checksum errors. But in real life 
experience, the ideal scene seems not always exist. We have customers 
meeting checksum bug's either from driver's software or a hardware 
issue. Customer will have one more option to address the problem if we 
provide this as an option.
>
>>>> I'm sort of ambivalent about the idea of having a per-driver "private"
>>>> set of properties in Brussels, because I think it'll be abused in
>>>> _exactly_ this way -- to provide unnecessary tweaks like the bcopy/DMA
>>>> limit or putnext/putq switch.
>>>>       
>>
>> Actually, I myself felt that bcopy/dma threshold, as well as
>> some of the ipg properties that have been suggested as public property
>> candidates, also fell in the "Advanced Usage" bucket..
>>   
>
> "Advanced usage" != debug usage.  Those values are perfectly 
> reasonable things for the customer to tune, at least as long as we 
> don't have a facility in place to auto-tune them.  (One could argue 
> that the bcopy/dma stuff should not be customer tunable, but right now 
> we don't have any facility to auto-tune them.  
This is somewhat similar to what we discussed about "interrupt 
coalecing", I think. Because we don't have a perfect auto-tuning way so 
far, we need to keep that somewhere.
> The ipg properties are definitely a customer tunable, and do represent 
> unusual/advanced usage, but they aren't something that we can 
> auto-tune for the customer.)
>
>>  
>>> Would it be good for us to retain them somehow in early phase of 
>>> Brussel, like by ways of keep it as "private" properties? For 
>>> backward compatibility reason, some customers might rely on those 
>>> private properties in their production env. Before we provide enough 
>>> tuning in framework, they will lose nothing.
>>>     
>>
>>   
>
> We need to be careful about how much we expose customers to, and what 
> guarantees we provide.  If we plan on removing certain values in the 
> future, we should definitely set that expectation with our customers.
Yes, I think so.
>
>    -- Garrett
>> I like Raymond's proposal..
>>
>> --Sowmini
>> _______________________________________________
>> brussels-dev mailing list
>> brussels-dev at opensolaris.org
>> http://opensolaris.org/mailman/listinfo/brussels-dev
>>   
>
> _______________________________________________
> networking-discuss mailing list
> networking-discuss at opensolaris.org