[openib-general] [PATCH] ping Add IB ping server agent

[shaharf]

Hi all,

	I saw that a lot of ping-pong flew around during (my) weekend
;-). I guess that I have few things to explain regarding the ibping.

First, the origin of the utility is in pathforward SOW. As I understand
it, the ibping (vping in the SOW) should imitate the ICMP ping and
should be used for basic/sanity connection checks. NodeDesc packets are
not enough because you cannot control there output to include additional
information, and you cannot be sure that the kernel is OK when you get
NodeDesc replies because some IB devices replies to the basic SMP mads
without the kernel knowledge (for example many managed switches, and all
non managed switches). I certainly do not want to force the current
openib gen2 host mad architecture where all mads are exposed to the
kernel before the firmware have a chance to reply on them.

Regarding the issue whether to have it in a separate source file and or
modules, I am not sure it is really important as long it is loaded by
default and therefore the diagnostics utilities may rely on it.

I agree with Sean that additional shared functionality is required. I
felt it was a bit stupid of me to replicate (again) this functionality,
but I didn't want to change too much of the code, especially due the
fact that these areas will (and are) affected by the RMPP functionality.

Sean has also a good point regarding the mad pool. I mimicked other
paths that Hal and other wrote, but now, after several paths use these
methods, it seems that we have to implement some cleaner send mad pools
instrumentation.  

Sorry about (not calling) ib_free_recv_mad() function - I am a bad boy
;-)

Regarding the content of the ping packet, I encountered many ideas in
the list, most of them good and valid. My opinion is that the kernel
server should reply only on the most basic "ping queries" and any
further ping enhancements (for example, returning gid + lid, etc.)
should be implemented in a separate, probably user mode server. This
will be the most flexible solution and will reduce the kernel pollution.
In fact I started to implement a (usermode only) "ibsystat service" that
will supply such extensions. Currently, what I have in mind is to
provide basic host information: number of CPUs, memory, utilization,
etc., IB information: number of hcas, models, etc. The idea is to ease
some cluster wide operations common in large cluster setup. Any ideas
and suggestions are welcomes. 

A word for Michael: it is true that QP0 should be kept for subnet
management only, but even though it is written in the Spec., I wouldn't
say that MADs of any sort should be assumed to be originated from the
SM. Specifically, the return address can be any lid and not just the
SMLid - because that are times where the SMLid is not configured, and
that many SM's may use direct mads (or any other type of mads) to
discover the network and/or to communicate among themselves. In fact
many of the utilities already existing in the gen2 diagnostics tree use
direct mads for many purposes. Let's say that the Spec phrasing is just
a sort of short seeing. Personally I extend the "SM" term to be "any
subnet management oriented entity"...
If you thing this is some kind of invalid behavior, you may be formally
right, but as long as multiple SM's are allowed to operate (one master,
many standbys), you can not disallow that so - "if you can't win them,
join them"... (you can check and see that the diags are not performing
anything that is not allowed by for a standby SM).
  
Finally, the existing (kernel) code is really preliminary. It is
supplied to get a foothold (meaning to allow the user mode diags to rely
on it), and to share the community with its implementation (an
overwhelming success indeed ;-).

Shahar