Hi Sean,
Some minor comments below.
On Tue, Oct 12, 2010 at 3:13 PM, Hefty, Sean sean.he...@intel.com wrote:
Export the mad snooping capability to user space clients
through the existing umad interface. This will allow
users to capture MAD data for debugging, plus it allows
for services to
By providing this mechanism, ib_usa provides a convenient and useful way for
user applications to detect when nodes enter or leave the fabric. This is
useful for fabric monitoring applications (like a system admin dashboard) or,
conceivably, to allow a job scheduler to react to problems and to
Export the mad snooping capability to user space clients
through the existing umad interface. This will allow
users to capture MAD data for debugging, plus it allows
for services to act on MAD traffic that occurs.
Should it also be noted that snooping of RMPP'd MADs occurs at the
Sean,
Would it be worthwhile to filter based on the source LID/GID of the MAD?
-Original Message-
From: linux-rdma-ow...@vger.kernel.org
[mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Hefty, Sean
Sent: Tuesday, October 12, 2010 3:11 PM
To: Linux RDMA list
Subject: [RFC 1/2]
On Thu, Oct 14, 2010 at 11:20 AM, Hefty, Sean sean.he...@intel.com wrote:
Export the mad snooping capability to user space clients
through the existing umad interface. This will allow
users to capture MAD data for debugging, plus it allows
for services to act on MAD traffic that occurs.
Would it be worthwhile to filter based on the source LID/GID of the MAD?
Without breaking the umad ABI, GID filtering would be difficult. LID is
possible, but I can't think of a good reason why the kernel should perform that
level of filtering. Ideas?
I have thought about using the
Well, the critical thing is that on a large fabric, capturing all the MADs
would be quite a firehose of data. Being able to filter on a single source or
destination would make the amount of data more manageable.
I'm flexible though, if the act of dumping all the data to a user-space app
Without breaking the umad ABI, GID filtering would be difficult. LID
is possible, but I can't think of a good reason why the kernel should
perform that level of filtering. Ideas?
How many MADs in real life even have a source GID?
- R.
--
To unsubscribe from this list: send the line
On Thu, Oct 14, 2010 at 01:12:52PM -0700, Roland Dreier wrote:
+ if (lrh_present) {
+ header-lrh.link_version = 0;
+ header-lrh.link_next_header =
+ grh_present ? IB_LNH_IBA_GLOBAL : IB_LNH_IBA_LOCAL;
+ packet_length = IB_LRH_BYTES;
On Thu, Oct 14, 2010 at 02:43:30PM -0700, Roland Dreier wrote:
void ib_ud_header_init(intpayload_bytes,
int lrh_present,
int eth_present,
int grh_present,
From: linux-rdma-ow...@vger.kernel.org [linux-rdma-ow...@vger.kernel.org] On
Behalf Of Eli Cohen [...@dev.mellanox.co.il]
Sent: Thursday, October 14, 2010 2:57 PM
To: Roland Dreier
Cc: RDMA list
Subject: Re: [PATCHv10 03/12] ib_core: IBoE UD packet
On Tue, 5 Oct 2010 08:55:47 +0200 Bernard Metzler wrote:
---
Documentation/networking/siw.txt | 91
++
1 files changed, 91 insertions(+), 0 deletions(-)
create mode 100644 Documentation/networking/siw.txt
diff --git
if (header-immediate_present)
This should be if (immediate_present).
header-immediate_present is zero due to the memset() above.
Thanks, fixed that up.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More
13 matches
Mail list logo
