<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.45">
<TITLE>RE: [openib-general] IPoIB IETF WG presentation updated again</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<P><FONT SIZE=2>> From: Roland Dreier [<A HREF="mailto:roland@topspin.com">mailto:roland@topspin.com</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Tuesday, August 03, 2004 12:52 AM</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Dror> I think that ideally, if a network device can replace the</FONT>
<BR><FONT SIZE=2>> Dror> ARP functionality in the kernel that'll be better. Because</FONT>
<BR><FONT SIZE=2>> Dror> this way the IPoIB can get an address resolution request</FONT>
<BR><FONT SIZE=2>> Dror> from the IP stack, handle it by sending an ARP, then SA</FONT>
<BR><FONT SIZE=2>> Dror> query for the path record, then creation of HCA address</FONT>
<BR><FONT SIZE=2>> Dror> handle, and then place it in cache and pass back this</FONT>
<BR><FONT SIZE=2>> Dror> address handle. When cache is replaced or expires, IPoIB</FONT>
<BR><FONT SIZE=2>> Dror> will destroy the HCA address handle. If this is not</FONT>
<BR><FONT SIZE=2>> Dror> supported, then IPoIB will still need to maintain a shadow</FONT>
<BR><FONT SIZE=2>> Dror> table.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> I don't think the networking maintainers will have much desire to see</FONT>
<BR><FONT SIZE=2>> pluggable ARP implementations. However it may be possible to use the</FONT>
<BR><FONT SIZE=2>> hard_header_cache() methods to handle the address vector stuff (I</FONT>
<BR><FONT SIZE=2>> haven't figured out if this can be made to work, this is just a vague</FONT>
<BR><FONT SIZE=2>> idea right now).</FONT>
<BR><FONT SIZE=2>> </FONT>
</P>
<P><FONT SIZE=2>What you're saying is that we'll have to maintain a shadow cache for the </FONT>
<BR><FONT SIZE=2>ARP table anyway. And that this table will be loosely synchronized with </FONT>
<BR><FONT SIZE=2>the OS ARP table (because you don't know when ARP table entry is invalidated,</FONT>
<BR><FONT SIZE=2>right?). </FONT>
<BR><FONT SIZE=2>I can understand why the kernel maintainers would rather not have a </FONT>
<BR><FONT SIZE=2>pluggable ARP cache, but the way IPoIB works today with the shadow</FONT>
<BR><FONT SIZE=2>ARP table doesn't look clean to me. Maybe it's possible to get a callback</FONT>
<BR><FONT SIZE=2>when the ARP table entry is invalidated ? </FONT>
<BR><FONT SIZE=2>BTW, I am not sure I understand how hard_header_cache() in net_device</FONT>
<BR><FONT SIZE=2>works...</FONT>
</P>
<P><FONT SIZE=2>> Dror> Beyond that, it'll be nice if we could have gotten the IP</FONT>
<BR><FONT SIZE=2>> Dror> datagram without the "Ethernet" header. Currently the IPoIB</FONT>
<BR><FONT SIZE=2>> Dror> driver has to chop it, and replace it with the IPoIB</FONT>
<BR><FONT SIZE=2>> Dror> encapsulation header. Anyway, this is just the purity of the</FONT>
<BR><FONT SIZE=2>> Dror> protocol stack layering.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Not sure where this is coming from -- the Linux kernel networking core</FONT>
<BR><FONT SIZE=2>> does not put an ethernet header in a packet. The network device's</FONT>
<BR><FONT SIZE=2>> hard_header method can do whatever it wants to set up the packet.</FONT>
<BR><FONT SIZE=2>> </FONT>
</P>
<P><FONT SIZE=2>Thanks. I wasn't aware of being able to override the default implementation of </FONT>
<BR><FONT SIZE=2>hard_header in net_device. So, I think I now understand how one would solve </FONT>
<BR><FONT SIZE=2>this cleanly. I looked at gen1 code and saw that the code for hard_header is </FONT>
<BR><FONT SIZE=2>currently doing what's Ether is doing. That was probably why I got confused </FONT>
<BR><FONT SIZE=2>from the first place...</FONT>
</P>
<P><FONT SIZE=2>-Dror</FONT>
</P>
</BODY>
</HTML>