[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130403154455.GM21481@macbook.localnet>
Date: Wed, 3 Apr 2013 17:44:55 +0200
From: Patrick McHardy <kaber@...sh.net>
To: Or Gerlitz <ogerlitz@...lanox.com>
Cc: jon.maloy@...csson.com, allan.stephens@...driver.com,
netdev@...r.kernel.org, roland@...nel.org, sean.hefty@...el.com,
hal.rosenstock@...il.com, linux-rdma@...r.kernel.org
Subject: Re: [PATCH 5/5] IPoIB: add support for TIPC protocol
On Wed, Apr 03, 2013 at 06:31:49PM +0300, Or Gerlitz wrote:
> On 03/04/2013 15:43, Patrick McHardy wrote:
> >[...] all TIPC needs to know about is ARP and RARP since
> >it wants to always perform "path find", even if a path is already known. [...]
>
> Not sure to follow this part... did you mean "all IPoIB needs to
> know about is ARP or RARP", this makes
> sense indeed, since for arp/rarp we want to call unicast_arp_send
> which does path_find and looks
> also for the case the path isn't valid
What I meant is that it doesn't require any knowledge about IPv4/IPv6 or
other higher layer protocols anymore. At least almost none.
We have protocol knowledge in ipoib_start_xmit(). For broadcast packets,
it drops unknown protocols. For unicast packets, it handles ARP/RARP
seperately because of the path find differences, IP/IPv6 are sent
using the neigh, all others are dropped.
ipoib_cm also has knowledge about IPv4/IPv6 in order to send ICMP errors.
What we could do instead of adding TIPC to the broadcast-don't-drop list
and to the send-using-neigh list in ipoib_start_xmit() is to only treat
ARP/RARP special and send every other protocol using the neigh or
ipoib_mcast_send().
Right now the supported protocols are artificially limited without a
technical reason.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists