netdev
[Top] [All Lists]

Re: Advice needed on IP-over-InfiniBand driver

To: hadi@xxxxxxxxxx
Subject: Re: Advice needed on IP-over-InfiniBand driver
From: Roland Dreier <roland@xxxxxxxxxxx>
Date: Tue, 21 Sep 2004 08:23:15 -0700
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <1095766554.1049.49.camel@xxxxxxxxxxxxxxxx> (jamal's message of "21 Sep 2004 07:35:54 -0400")
References: <52fz5esxx6.fsf@xxxxxxxxxxx> <20040919140133.60ea3fb3.davem@xxxxxxxxxxxxx> <1095628759.1049.22.camel@xxxxxxxxxxxxxxxx> <52y8j5r1d6.fsf@xxxxxxxxxxx> <1095766554.1049.49.camel@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux)
    jamal> Are you doing the path manager from user space or kernel?
    jamal> Its easy to generate netlink events to user space; you
    jamal> could then have the manager create path from user space.

The subnet manager (== big application that assigns paths to everyone
on a fabric, etc) will be in user space running on a single node.  But
I would prefer to have the IPoIB driver be contained within the kernel
to avoid complications like needing to start a userspace helper from
an initrd for NFS root, etc.  Sending path queries to the subnet
manager is pretty simple so I don't think there's an issue with having
that piece of code in the kernel.

Also, if the path record lookup is done in userspace, it seems the
driver will be passed 20-byte hardware addresses and need to look up
the path in some shadow ARP table for every packet, which doesn't seem
very efficient.

I'd like to understand David's approach better, since it seems he
knows how to avoid that.  Unfortunately I don't understand the
hard_header_cache() etc. methods well enough for his original
explanation to make sense to me.  Hopefully he'll have time to explain
in a little more detail...

Thanks,
  Roland


<Prev in Thread] Current Thread [Next in Thread>