netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roland Dreier <roland@topspin.com>
To: "David S. Miller" <davem@davemloft.net>
Cc: netdev@oss.sgi.com
Subject: Re: Advice needed on IP-over-InfiniBand driver
Date: Mon, 27 Sep 2004 21:41:12 -0700	[thread overview]
Message-ID: <52r7onc8ev.fsf@topspin.com> (raw)
In-Reply-To: <20040919140133.60ea3fb3.davem@davemloft.net> (David S. Miller's message of "Sun, 19 Sep 2004 14:01:33 -0700")

I've been mulling over the previous advice I got and reading over the
networking code, and I hope I have some more intelligent questions
now.  It seems I really have two somewhat independent issues to
resolve with respect to IP-over-IB address resolution:

 - IPoIB adds a second InfiniBand-specific path record lookup after
   the normal ARP/ND lookup.  I think I have a handle on how this can
   be added to net/ipv4/arp.c.

 - For InfiniBand, the layer 2 header is built and parsed by the
   hardware without a chance for software to see it.  In fact, once we
   have completed the 2 stage resolution as described above, the
   network driver has to pass this path information to the IB hardware
   and get an "address handle" back, which it uses to actually send
   packets.  It seems the existing hard_header, hard_header_cache and
   header_cache_update are not really applicable.

   My ideal solution would be some way for the driver have the packets
   passed to its hard_start_xmit method with the address handle in the
   skb->cb field (or another field if it's acceptable/desirable to add
   a field for this to struct sk_buff -- I notice a number of
   #ifdef'ed fields in there already, but I'm not sure if that type of
   thing is just old cruft or still OK).

   Also it would be nice is that address handle could be taken
   directly from the struct neighbor -- after all, we should be able
   to get it without requiring the driver to do any lookup from HW
   address to address handle.

   Finally, address handles need to be freed eventually, and I
   don't see a way for a driver to find out when an ARP entry is being
   destroyed.  Am I missing something, or is this something else I'll
   need to add?  What would be an acceptable way to add this to the
   networking code?

I'd really appreciate another dose of cluestick...

Thanks,
  Roland

  parent reply	other threads:[~2004-09-28  4:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-19  4:08 Advice needed on IP-over-InfiniBand driver Roland Dreier
2004-09-19 21:01 ` David S. Miller
2004-09-19 21:19   ` jamal
2004-09-20  2:34     ` David S. Miller
2004-09-20  4:51       ` Roland Dreier
2004-09-20  4:49     ` Roland Dreier
2004-09-21 11:35       ` jamal
2004-09-21 15:23         ` Roland Dreier
2004-09-20  4:42   ` Roland Dreier
2004-09-28  4:41   ` Roland Dreier [this message]
2004-09-28  4:52     ` David S. Miller
2004-09-30 18:41       ` Roland Dreier
2004-09-30 21:21         ` David Stevens
2004-09-30 21:48           ` Roland Dreier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52r7onc8ev.fsf@topspin.com \
    --to=roland@topspin.com \
    --cc=davem@davemloft.net \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).