<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [openib-general] IPoIB IETF WG presentation updated again</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1400" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi Dror,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT size=2>> It's good to see that MAX_ADDR_LEN has been changed to
32. Does that solve</FONT> <BR><FONT size=2>> all the IPoIB ARP related
problems for 2.6 kernel ? </FONT><FONT size=2>Can we store all related
link</FONT> <BR><FONT size=2>> information in this 32 bytes ? What is
envisioned to be stored in this 32 bytes - is</FONT> <BR><FONT size=2>> it
just the QPN+GID, or the entire path info, or the address vector object too
?</FONT> </DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>If it holds 32 bytes, then it can hold GID + QPN with 13
bytes still available.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Other information you might want to hold:<BR>SL 1
bytes</FONT></DIV>
<DIV><FONT size=2>LID 2 bytes</FONT></DIV>
<DIV><FONT size=2>
<DIV><FONT face=Arial size=2>MTU (for connected mode) (1 byte)</FONT></DIV>
<DIV><FONT face=Arial>Rate (1 byte)</FONT></DIV></FONT></DIV>
<DIV><FONT size=2>Network Layer</FONT></DIV>
<DIV><FONT size=2>Flow Label 3 bytes (20 bits)</FONT></DIV>
<DIV><FONT size=2>Hop Limit 1 byte</FONT></DIV>
<DIV><FONT size=2>TClass 1 byte</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>So all the info for an AV could be stored there.
Did I miss something needed ? I didn't </FONT></DIV>
<DIV><FONT face=Arial size=2>double check this but there is still some room left
over.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT size=2>> I think that ideally, if a network device can replace the
ARP functionality in the kernel</FONT> <BR><FONT size=2>> that'll be better.
Because this way the IPoIB can get an address resolution request
</FONT><BR><FONT size=2>> from the IP stack, handle it by sending an ARP,
then SA query for the path record, then</FONT> <BR><FONT size=2>> creation of
HCA address handle, and then place it in cache and pass back this address</FONT>
<BR><FONT size=2>> handle. When cache is replaced or expires, IPoIB will
destroy the HCA address handle.</FONT> <BR><FONT size=2>> If this is not
supported, then IPoIB will still need to maintain a shadow table.</FONT> </DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Cloning an AH is probably faster than creating a new one from
scratch. (We would need</FONT></DIV>
<DIV><FONT size=2>an additional verb for this). How much does this cost ? Is
this optimization worth it ?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=2>> Beyond that, it'll be nice if we could have gotten the IP
datagram without the "Ethernet"</FONT> <BR><FONT size=2>> header. Currently
the IPoIB driver has to chop it, and replace it with the IPoIB
encapsulation</FONT> <BR><FONT size=2>> header. Anyway, this is just the
purity of the protocol stack layering.</FONT> </DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>There would need to be another way to identify the various
protocols (aka ethertypes) being carried.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>-- Hal</FONT></DIV></BODY></HTML>