[openib-general] IPoIB IETF WG presentation updated again

[Dror Goldenberg]

> From: Roland Dreier [mailto:roland at topspin.com]
> Sent: Tuesday, August 03, 2004 12:52 AM
> 
> 
>     Dror> I think that ideally, if a network device can replace the
>     Dror> ARP functionality in the kernel that'll be better. Because
>     Dror> this way the IPoIB can get an address resolution request
>     Dror> from the IP stack, handle it by sending an ARP, then SA
>     Dror> query for the path record, then creation of HCA address
>     Dror> handle, and then place it in cache and pass back this
>     Dror> address handle. When cache is replaced or expires, IPoIB
>     Dror> will destroy the HCA address handle.  If this is not
>     Dror> supported, then IPoIB will still need to maintain a shadow
>     Dror> table.
> 
> I don't think the networking maintainers will have much desire to see
> pluggable ARP implementations.  However it may be possible to use the
> hard_header_cache() methods to handle the address vector stuff (I
> haven't figured out if this can be made to work, this is just a vague
> idea right now).
> 

What you're saying is that we'll have to maintain a shadow cache for the 
ARP table anyway. And that this table will be loosely synchronized with 
the OS ARP table (because you don't know when ARP table entry is
invalidated,
right?). 
I  can understand why the kernel maintainers would rather not have a 
pluggable ARP cache, but the way IPoIB works today with the shadow
ARP table doesn't look clean to me. Maybe it's possible to get a callback
when the ARP table entry is invalidated ? 
BTW, I am not sure I understand how hard_header_cache() in net_device
works...

>     Dror> Beyond that, it'll be nice if we could have gotten the IP
>     Dror> datagram without the "Ethernet" header. Currently the IPoIB
>     Dror> driver has to chop it, and replace it with the IPoIB
>     Dror> encapsulation header. Anyway, this is just the purity of the
>     Dror> protocol  stack layering.
> 
> Not sure where this is coming from -- the Linux kernel networking core
> does not put an ethernet header in a packet.  The network device's
> hard_header method can do whatever it wants to set up the packet.
> 

Thanks. I wasn't aware of being able to override the default implementation
of 
hard_header in net_device.  So, I think I now understand how one would solve

this cleanly. I looked at gen1 code and saw that the code for hard_header is

currently doing what's Ether is doing. That was probably why I got confused 
from the first place...

-Dror

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