[openib-general] IPoIB IETF WG presentation updated again

[Hal Rosenstock]

RE: [openib-general] IPoIB IETF WG presentation updated againHi Dror,

> It's good to see that MAX_ADDR_LEN has been changed to 32. Does that solve 
> all the IPoIB ARP related problems for 2.6 kernel ? Can we store all related link 
> information in this 32 bytes ? What is envisioned to be stored in this 32 bytes - is 
> it just the QPN+GID, or the entire path info, or the address vector object too ? 

If it holds 32 bytes, then it can hold GID + QPN with 13 bytes still available.

Other information you might want to hold:
SL 1 bytes
LID 2 bytes
MTU (for connected mode) (1 byte)
Rate (1 byte)
Network Layer
Flow Label 3 bytes (20 bits)
Hop Limit 1 byte
TClass 1 byte

So all the info for an AV could be stored there. Did I miss something needed ? I didn't 
double check this but there is still some room left over.

> I think that ideally, if a network device can replace the ARP functionality in the kernel 
> that'll be better. Because this way the IPoIB can get an address resolution request 
> from the IP stack, handle it by sending an ARP, then SA query for the path record, then 
> creation of HCA address handle, and then place it in cache and pass back this address 
> handle. When cache is replaced or expires, IPoIB will destroy the HCA address handle. 
> If this is not supported, then IPoIB will still need to maintain a shadow table. 

Cloning an AH is probably faster than creating a new one from scratch. (We would need
an additional verb for this). How much does this cost ? Is this optimization worth it ?

> Beyond that, it'll be nice if we could have gotten the IP datagram without the "Ethernet" 
> header. Currently the IPoIB driver has to chop it, and replace it with the IPoIB encapsulation 
> header. Anyway, this is just the purity of the protocol  stack layering. 

There would need to be another way to identify the various protocols (aka ethertypes) being carried.

-- Hal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20040803/d92221f4/attachment.html>