2008/688 Sun Cluster TCP/IP Hooks Update

[Honsing Cheng]

Huafeng Lu wrote:

> 于 2008年11月12日 14:49, Erik Nordmark 写道:
>> James Carlson wrote:
>>
>>>   The situation for UDP is a bit different.  Since there is no real
>>>   connection in UDP and the same socket can be used to send to
>>>   multiple destinations, the major task is to register the five-tuple
>>>   at the cluster level.  Such registration is performed at connect(),
>>>   sendto() and sendmsg(), which call the cl_inet_connect() hook at
>>>   proper time.  For performance reasons, sendto()/sendmsg() calls the
>>>   hook only when the destination is new.  To facilitate this, two new
>>>   fields are added to the udp_t struct to store the most recent
>>>   destination address and port: in6_addr_t udp_cl_v6lastdst; in_port_t
>>>   udp_cl_lastdstport; In a sendto() or sendmsg(), the
>>>   cl_inet_connect() hook is called only when the destination is
>>>   different from most recent one.
> 
> [ cc Honsing from the Cluster team.]
> 
> 
> Hi Erik,
> 
> Thanks for reviewing it.
> 
>> Since UDP currently does not call cl_inet_connect, I assume the above 
>> paragraph refers to the proposed new behavior.
> 
> Yes, for the new behavior.
>>
>> Does the reference to sendmsg/sendto imply that this will be 
>> implemented in sockfs? Or will it be implemented in TCP?
> 
> When sendmsg/sendto are called from an application, the registrations 
> are finally implemented in udp_wput(). You can refer to the webrev at 
> http://greatwall.prc/~hl157128/tmp.cluster/webrev.stonedog.1111/
>>
>> I don't understand why a new udp_cl_v6lastdst is needed since udp 
>> already has a udp_v6lastdst field.
> 
> The udp_v6lastdst field is used for Trusted Extension. To be safe, I 
> don't want to reuse it, so the two new fields are introduced.
>>
>>
>> Is the intent that Cluster be useful with exclusive-IP zones in the 
>> future?
>> If so it might make sense to take this opportunity to introduce an 
>> instance identifier to the function signatures.


Currently the load balancing feature is limited to shared-IP zones. But we do believe that at some 
future point we would like to expand it to include exclusive-IP zones. So if it is relatively 
straight-forward to include the instance ID, we should pursue it.

Honsing

> 
> The requirement for this project (RFE 6717519) comes from a customer 
> (Siemens). Using Cluster with exclusive zones is not in the requirement. 
> I don't know if this will happen in the future.
> 
> Honsing is from the Cluster team, so he may provide such information.
> 
> Thanks.
> -- 
> Huafeng
> 
> 
>>
>>    Erik
>>
>