On Thu, 2005-03-17 at 13:52, Roland Dreier wrote:
> Hal> An entire range of IB ping types could be implemented
> Hal> analagous to ICMP types.
>
> Given that the current code seems to send a reply without looking at
> the attribute ID or anything else about the query packet, how are we
> g
On Thu, 2005-03-17 at 13:50, Roland Dreier wrote:
> Hal> Also, the ability to support various options such as: length
> Hal> based query/response
>
> Given that MAD packets are always exactly 256 bytes long, is this useful?
The vendor MAD class range 2 supports RMPP so this is not necessa
Hal> An entire range of IB ping types could be implemented
Hal> analagous to ICMP types.
Given that the current code seems to send a reply without looking at
the attribute ID or anything else about the query packet, how are we
going to handle backwards compatibility?
- R.
___
Roland> One other thought just occurred to me -- what advantages
Roland> does this vendor-specific ping MAD have over a LID-routed
Roland> NodeDescription get query?
Hal> No MKey issue is the first thing that comes to mind.
Hmm... is someone running their fabric with an M_Key prot
Hal Rosenstock wrote:
An entire range of IB ping types could be implemented analagous to ICMP
types.
This is more of a reason to break this out into a separate module.
- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mail
On Thu, 2005-03-17 at 11:38, Roland Dreier wrote:
> One other thought just occurred to me -- what advantages does this
> vendor-specific ping MAD have over a LID-routed NodeDescription get query?
No MKey issue is the first thing that comes to mind.
Also, the ability to support various options suc
Hal> An entire range of IB ping types could be implemented
Hal> analagous to ICMP types.
Seems like a good argument for splitting the support out into its own
source file at least.
- R.
___
openib-general mailing list
openib-general@openib.org
Hi Eitan,
On Thu, 2005-03-17 at 11:55, Eitan Zahavi wrote:
> If the response would have included the guid and lid of the responding
> port this could potentially be used to validate path record cache in a
> distributed manner...
>
> Also could help in diagnostics.
An entire range of IB ping type
On Thu, 2005-03-17 at 12:38, Sean Hefty wrote:
> Roland Dreier wrote:
> > I would suggest moving the ping server at least into its own source
> > file, if not into its own module. I'm not convinced that we want to
> > have a vendor-specific MAD handler unconditionally compiled into the
> > core MA
Roland Dreier wrote:
I would suggest moving the ping server at least into its own source
file, if not into its own module. I'm not convinced that we want to
have a vendor-specific MAD handler unconditionally compiled into the
core MAD support.
I agree with this. This feels like it should be a sep
Eitan> Hi Hal, If the response would have included the guid and
Eitan> lid of the responding port this could potentially be used
Eitan> to validate path record cache in a distributed manner...
Eitan> Also could help in diagnostics.
Sort of like a LID-routed query of PortInfo?
- R
Title: RE: [openib-general] [PATCH] agent: Add IB ping server agent
Hi Hal,
If the response would have included the guid and lid of the responding port this could potentially be used to validate path record cache in a distributed manner...
Also could help in diagnostics.
Eitan Zahavi
Hal> One more thing: This is analagous to the (ICMP) ping server
Hal> built into the kernel.
Sort of, except it's not part of the IB spec. ICMP and in particular
ICMP echo support is a "MUST" for any RFC-compliant IP implementation.
One other thought just occurred to me -- what advantage
On Thu, 2005-03-17 at 10:11, Roland Dreier wrote:
> I would suggest moving the ping server at least into its own source
> file, if not into its own module. I'm not convinced that we want to
> have a vendor-specific MAD handler unconditionally compiled into the
> core MAD support.
>
> It might mak
On Thu, 2005-03-17 at 10:11, Roland Dreier wrote:
> I would suggest moving the ping server at least into its own source
> file, if not into its own module. I'm not convinced that we want to
> have a vendor-specific MAD handler unconditionally compiled into the
> core MAD support.
Moving this into
I would suggest moving the ping server at least into its own source
file, if not into its own module. I'm not convinced that we want to
have a vendor-specific MAD handler unconditionally compiled into the
core MAD support.
It might make some sense to have the option of handling ping packets
in ke
agent: Add IB ping server agent (used with ibping diagnostic tool)
Signed-off-by: Shahar Frank <[EMAIL PROTECTED]>
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: include/ib_mad.h
===
--- include/ib_mad.h(revision 2012)
17 matches
Mail list logo
