Re: [openib-general][patch review] srp: fmr implementation,

[Vu Pham]

BTW, does Mellanox (or anyone else) have any numbers showing that
using FMRs makes any difference in performance on a semi-realistic benchmark?



I'm using xdd to test the performance 
www.ioperformance.com/products.htm


The target is Mellanox srp target reference implemenation 
with 14 SATA spindles


I can get ~780 MB/s max without FMRs and ~920 MB/s with FMRs 
(using 256 KB sequential read direct IO request)



Wow, that's awesome Vu! 

So what's the consensus on the reason for the improvement? 
- Fewer WR to send the same amount of data because the memory is

virtually contiguous?


Fewer wqe, fewer interrupts & context switches, big I/O 
request directly sent to back-end storage/spindles (all are 
applied for target)


For write command (RDMA read), it help to utilize the max 
outstanding rdma read operations (more data transfer per 
outstanding rdma read operations)



- Fewer PDU due to larger writes and better packing?


This is not much.


- Something else?

Are these huge reads, ... or even better ... what are the parameters to
xdd?



-op read -reqsize 128 -block 2048 -dio -mbytes 8192 
-targetdir /dev/ -targets 14 sdb sdc sdd 





Did you quantify the FMR registration cost per MB of registered memory
space? This would be a very good number to have for figuring out where
the sweet spot is...


I don't have this number of FMR registration cost per MB.

Dror, do we have any number on how many cycles cost per FMR 
registration?


On the side note the FMR registration hit rate is ~100% with 
direct I/O


Vu
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] question regarding GRH flag in ib_ah_attr

[Jason Gunthorpe]

On Wed, May 10, 2006 at 09:56:58PM -0700, Roland Dreier wrote:
> Hal> Huh ? In this case, aren't the subnet prefixes are required
> Hal> to be different ?
> 
> It's kind of a crazy thing to do but I don't see anything in the IB
> spec that forbids two subnets with the same subnet prefix, or any
> reason why a router couldn't route between them.  The SMs would just
> have to be smart enough to return the LID of the router for paths to
> ports on the other subnet, and the routers would have to have explicit
> routes rather than forwarding based on just GID prefix.

Hmm, this is an interesting point, you can do this in IP land using
host routes.

How about this - the Path record (and related) SA responses include
the Hop Limit fields and the spec says:

8.3.6 Hop Limit: [..] Setting this value to 0 or 1 will ensure that
the packet will not be forwarded beyond the local subnet.

So, it is within the spec to use HopLmt >= 2 as the GRH required flag.

I'd propose that the combination of a non-link-local prefix and a >= 2
Hop Limit should force a GRH. SM's that do not support routers should
always fill in 0 for HopLmt.

Jason
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: 2.6.17 and 2.6.18 merge plans

[Michael S. Tsirkin]

Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: 2.6.17 and 2.6.18 merge plans
> 
> As the 2.6.17 release cycle starts to wrap up, I thought it would be a
> good time to send out a report on my status, and a request for patches.
> 
> All I have queued up for 2.6.17 that isn't upstream already is the
> one-liner patch fixing the ipath PCI device ID table.  If there is
> anything else you think should be in 2.6.17, please send me a patch
> against the for-2.6.17 branch of my git tree [1]. 

How about module unloading races? Solving them by flushing WQs is not
very elegant but no better solution surfaced either. Should I repost
the patches?

-- 
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH 0/6] iSER (iSCSI Extensions for RDMA) initiator

[Or Gerlitz]

On 5/11/06, Roland Dreier <[EMAIL PROTECTED]> wrote:

Or> OK., I see now that as of few hours ago the second iscsi
Or> update for 2.6.18 was commited there which means iser should
Or> compile with it, you can go ahead pull it!

Great, I've got it.  Can you resend the iSER patches with changelog
entries for each patch and a Signed-off-by: line too?


sure, will do that

Or.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH][UVERBS][RFC] node type in ibv_context

[Roland Dreier]

Tom> Yeah, I originally had it there, but I waffled because I was
Tom> worried (no use case btw) if the type check was every in the
Tom> performance path that it would involve one extra pointer
Tom> dereference.

That's a valid point.  But that seems like a pathologically stupid
app to me, to be honest.

 - R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] 2.6.17 and 2.6.18 merge plans

[Roland Dreier]

Grant> SDP is still missing.  I just think SDP is a substantial
Grant> peice of the story for IB adoption.  Sorry, I won't be able
Grant> to contribute much here.

It doesn't seem very realistic to expect to merge SDP for 2.6.18.  The
current codebase is very much a work in progress that has never been
reviewed by anyone and is not really ready for review, and I would
expect SDP to take a while to review even once it's ready for review.

 - R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] question regarding GRH flag in ib_ah_attr

[Roland Dreier]

Hal> What you are describing is similar to a NAT function for IB
Hal> which would need to be supported in the IB edge router to
Hal> that private network.

Why does there have to be any NAT?  The router would just have to
replace the DLID the same as it usually does.  I don't see why the GID
prefix makes any difference really.

 - R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] question regarding GRH flag in ib_ah_attr

[Roland Dreier]

Hal> Huh ? In this case, aren't the subnet prefixes are required
Hal> to be different ?

It's kind of a crazy thing to do but I don't see anything in the IB
spec that forbids two subnets with the same subnet prefix, or any
reason why a router couldn't route between them.  The SMs would just
have to be smart enough to return the LID of the router for paths to
ports on the other subnet, and the routers would have to have explicit
routes rather than forwarding based on just GID prefix.

 - R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] ip over ib throughtput

[Shirley Ma]

"Talpey, Thomas" <[EMAIL PROTECTED]>
wrote on 05/10/2006 03:10:57 PM:
> Sure, but I wonder why it's interesting. Nobody ever uses NFS in such
> small blocksizes, and 2044 bytes would mean, say, 1800 bytes of payload.
> What data are you looking for, throughput and overhead? Direct RDMA,
> or inline?
> 
> Tom. 

Throughput. I am wondering how much room IPoIB performance
(throughput) can go. 

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone(Fax): (503) 578-7638___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re:

[yukihana]

完┃全┃無┃料┃＆┃使┃い┃放┃題┃
━┛━┛━┛━┛━┛━┛━┛━┛━┛
　　▽▽
http://love-match.bz/pc/?02
 
◆入会費／年会費→→→無料
◇メール受信＆送信→→無料
◆理想の相手／ご近所検索→→→無料
◇写真／動画の登録＆閲覧→→→無料
◆住所／アドレス／電話番号の交換→→→無料
 
男性♂女性♀ともに完全無料で全てご利用頂けます。
http://love-match.bz/pc/?02
 
安心サイト宣言
・・・…━★
当番組はスポンサーサイト様からの広告料のみで運営しております。
その為、全サービスを完全無料で全てご利用頂けます。
理想の相手を求める方々に安心と信頼を第一に考えながら、
気軽にお使い頂けるサービスを目指し、
万全のサポート体制で皆様に合ったお相手探しをお手伝いしております。
★━…・・・

http://ad.deai-ciao.net/?hkbb

広東省茂名市人民大街3-6-4-533
友誼網絡公司
139-3668-7892



___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] question regarding GRH flag in ib_ah_attr

[Hal Rosenstock]

On Wed, 2006-05-10 at 21:26, Hal Rosenstock wrote:
> On Wed, 2006-05-10 at 19:44, Roland Dreier wrote:
> > Sean> Does anyone know how the user determines if the grh flag
> > Sean> should be set in the ib_ah_attr when allocating an ib_ah?
> > Sean> Do they do this by examining the GIDs in a path record?
> > 
> > Good question.  It's always needed for multicast, of course.  For
> > unicast, I guess one could look at whether the subnet prefixes of the
> > SGID and DGID are the same, but I'm not sure that's sufficient -- a
> > router could conceivably sit between two subnets with the same subnet
> > prefix.
> 
> Huh ? In this case, aren't the subnet prefixes are required to be
> different ?

Not just different but globally unique, right ? 

What you are describing is similar to a NAT function for IB which would
need to be supported in the IB edge router to that private network.

-- Hal

> 
> -- Hal
> 
> > Perhaps some of the Obsidian guys could comment?
> > 
> >  - R.
> > ___
> > openib-general mailing list
> > openib-general@openib.org
> > http://openib.org/mailman/listinfo/openib-general
> > 
> > To unsubscribe, please visit 
> > http://openib.org/mailman/listinfo/openib-general
> 
> ___
> openib-general mailing list
> openib-general@openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] question regarding GRH flag in ib_ah_attr

[Hal Rosenstock]

On Wed, 2006-05-10 at 19:35, Sean Hefty wrote:
> For context, I'm trying to work backwards from send a message on a UD QP to
> determine what information is needed and how it is obtained.
> 
> Does anyone know how the user determines if the grh flag should be set in the
> ib_ah_attr when allocating an ib_ah?  Do they do this by examining the GIDs 
> in a
> path record?

Anytime the send is off the local subnet (as well as multicast), a GRH
is required. Also, there is a management response rule for responding
when the request contained a GRH that require a GRH (13.5.4.4 p. 769).

-- Hal

> 
> - Sean
> ___
> openib-general mailing list
> openib-general@openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] question regarding GRH flag in ib_ah_attr

[Hal Rosenstock]

On Wed, 2006-05-10 at 19:44, Roland Dreier wrote:
> Sean> Does anyone know how the user determines if the grh flag
> Sean> should be set in the ib_ah_attr when allocating an ib_ah?
> Sean> Do they do this by examining the GIDs in a path record?
> 
> Good question.  It's always needed for multicast, of course.  For
> unicast, I guess one could look at whether the subnet prefixes of the
> SGID and DGID are the same, but I'm not sure that's sufficient -- a
> router could conceivably sit between two subnets with the same subnet
> prefix.

Huh ? In this case, aren't the subnet prefixes are required to be
different ?

-- Hal

> Perhaps some of the Obsidian guys could comment?
> 
>  - R.
> ___
> openib-general mailing list
> openib-general@openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH][UVERBS][RFC] node type in ibv_context

[Tom Tucker]

On Mon, 2006-05-01 at 22:13 -0700, Roland Dreier wrote:
> Tom> Here's a patch that puts a node_type in the ibv_context.
> 
> Two problems:
>  - It breaks the ABI (which is frozen for the libibverbs 1.0 series)
>  - Even when we're ready to break ABI, I think node_type should be in
>struct ibv_device since it's not per-context at all.
> 

Yeah, I originally had it there, but I waffled because I was worried (no
use case btw) if the type check was every in the performance path that
it would involve one extra pointer dereference.
 
>  - R.

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] 2.6.17 and 2.6.18 merge plans

[Grant Grundler]

On Wed, May 10, 2006 at 04:41:40PM -0700, Roland Dreier wrote:
...
> For 2.6.18, I have the following major things already queued (in
> addition to a trivial mthca patch):

SDP is still missing.
I just think SDP is a substantial peice of the story for IB adoption.
Sorry, I won't be able to contribute much here.

thanks,
grant
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

RE: [openib-general] rdma_cm.h: comment nits.

[Tom Tucker]

On Wed, 2006-05-10 at 14:20 -0700, Caitlin Bestler wrote:
> Tom Tucker wrote:
> 
> > 
> > So... all that said, I could in fact support rdma_reject on
> > an active side connection. But this would effectively reduce
> > to a QP --> ERROR and I doubt this matches the semantics
> > you're looking for.
> > 
> > 
> 
> And you could send an RST. 

Yep, in fact that's what many RNIC's do when you move the QP to ERROR
instead of CLOSING. 

> There's just no way to send any user
> supplied private data. It's not just unreliable, it's guaranteed
> not to arrive. It's still a long way from the truly desired
> semantics, but the wire protocol just doesn't carry that info.
> 

Yeah, I think you're correct -- it would be a bogus "emulation".

> 

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general][patch review] srp: fmr implementation,

[Tom Tucker]

On Wed, 2006-05-10 at 08:36 -0700, Vu Pham wrote:
> Roland Dreier wrote:
> > BTW, does Mellanox (or anyone else) have any numbers showing that
> > using FMRs makes any difference in performance on a semi-realistic 
> > benchmark?
> > 
> 
> I'm using xdd to test the performance 
> www.ioperformance.com/products.htm
> 
> The target is Mellanox srp target reference implemenation 
> with 14 SATA spindles
> 
> I can get ~780 MB/s max without FMRs and ~920 MB/s with FMRs 
> (using 256 KB sequential read direct IO request)

Wow, that's awesome Vu! 

So what's the consensus on the reason for the improvement? 
- Fewer WR to send the same amount of data because the memory is
virtually contiguous?
- Fewer PDU due to larger writes and better packing?
- Something else?

Are these huge reads, ... or even better ... what are the parameters to
xdd?

Did you quantify the FMR registration cost per MB of registered memory
space? This would be a very good number to have for figuring out where
the sweet spot is...

Thanks,
Tom T.
> 
> Vu
> ___
> openib-general mailing list
> openib-general@openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] question regarding GRH flag in ib_ah_attr

[Jason Gunthorpe]

On Wed, May 10, 2006 at 04:44:42PM -0700, Roland Dreier wrote:
> Sean> Does anyone know how the user determines if the grh flag
> Sean> should be set in the ib_ah_attr when allocating an ib_ah?
> Sean> Do they do this by examining the GIDs in a path record?
> 
> Good question.  It's always needed for multicast, of course.  For
> unicast, I guess one could look at whether the subnet prefixes of the
> SGID and DGID are the same, but I'm not sure that's sufficient -- a
> router could conceivably sit between two subnets with the same subnet
> prefix.
 
> Perhaps some of the Obsidian guys could comment?

Our intention in the absence of standardization is to leverage common
practice in IPv6 for numbering - which means that global prefixes need
to be globally unique (or at least site unqiue). A generic N port
router cannot connect subnets with the same prefix because it
is ambiguous where to send the packets.

Logically I think the GRH usage should be selected after the output
port is determined based on matching the port's PortInfo.GIDPrefix and
the IBA default prefix (the link local prefix FE80:: which is always
on-link) against the DGID. If there is a match it is on link,
otherwise it is off link, through a router, and a GRH is necessary.

Right now IBA only allows two prefixes, FE80:: and PortInfo.GIDPrefix
so the check described above can be reduced to comparing the SGID and
DGID prefixes, if they are different and the DGID prefix is not FE80::
then it is off link and needs a GRH.

Regards,
Jason
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general][patch review] srp: fmr implementation,

[Tom Tucker]

On Wed, 2006-05-10 at 08:53 -0700, Roland Dreier wrote:
> Thomas> I am planning to test this some more in the next few
> Thomas> weeks, but what I'd really like to see is an IBTA
> Thomas> 1.2-compliant implementation, and one that operated on
> Thomas> work queue entries (not synchronous verbs). Is that being
> Thomas> worked on?
> 
> No current hardware supports that as far as I know.  (Well, ipath
> could fake it since they already implement all the verbs in software)
> 

I'm almost certain I'll be shot for saying this, but isn't there a
danger of confusion with real FMRs when the HW shows up? If the benefit
isn't there -- why do it if the application outcomes are almost
certainly all bad?


>  - R.
> ___
> openib-general mailing list
> openib-general@openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

RE: [openib-general] 2.6.17 and 2.6.18 merge plans

[Sean Hefty]

> - CMA.  Sean, I think there have been a lot of updates to the cma
>   since the last time you updated me.  Can you send me a patch to
>   resync my for-2.6.18 branch with the latest code for upstream?

I will start on this by the end of the week.

- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] question regarding GRH flag in ib_ah_attr

[Roland Dreier]

Sean> Does anyone know how the user determines if the grh flag
Sean> should be set in the ib_ah_attr when allocating an ib_ah?
Sean> Do they do this by examining the GIDs in a path record?

Good question.  It's always needed for multicast, of course.  For
unicast, I guess one could look at whether the subnet prefixes of the
SGID and DGID are the same, but I'm not sure that's sufficient -- a
router could conceivably sit between two subnets with the same subnet
prefix.

Perhaps some of the Obsidian guys could comment?

 - R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] 2.6.17 and 2.6.18 merge plans

[Roland Dreier]

As the 2.6.17 release cycle starts to wrap up, I thought it would be a
good time to send out a report on my status, and a request for patches.

All I have queued up for 2.6.17 that isn't upstream already is the
one-liner patch fixing the ipath PCI device ID table.  If there is
anything else you think should be in 2.6.17, please send me a patch
against the for-2.6.17 branch of my git tree [1].  I know pathscale at
least is sitting on ipath patches, and the window to get them into
2.6.17 is probably not all that big.

For 2.6.18, I have the following major things already queued (in
addition to a trivial mthca patch):

 - CMA.  Sean, I think there have been a lot of updates to the cma
   since the last time you updated me.  Can you send me a patch to
   resync my for-2.6.18 branch with the latest code for upstream?

 - SRP FMRs.

In addition I am planning on the following for 2.6.18 already:

 - iSER.  Just waiting for Or to send patches with proper changelogs
   and Signed-off-by: lines.

 - SRP tunable parameters.  I just need to review and merge the
   patches, but I don't expect any holdup here.

If there's something else you would like merged for 2.6.18, please
send out patches soon, so that they can be reviewed and ready to go
when 2.6.18 opens up.

Thanks,
  Roland

[1]  My git tree can be cloned from
 git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] question regarding GRH flag in ib_ah_attr

[Sean Hefty]

For context, I'm trying to work backwards from send a message on a UD QP to
determine what information is needed and how it is obtained.

Does anyone know how the user determines if the grh flag should be set in the
ib_ah_attr when allocating an ib_ah?  Do they do this by examining the GIDs in a
path record?

- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH] IB/ipath: Properly terminate PCI ID table

[Bryan O'Sullivan]

On Wed, 2006-05-10 at 15:38 -0700, Roland Dreier wrote:

> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>

Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Ephedra for you again

[Melissa Neu]

This is a multi-part message in MIME format.
--002_Dragon262767091951
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

on provision it aerate or resist and marginal a broadcast 

--002_Dragon940146732992
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit





Dunning Lucy






Ephedra Is Back and Legal


Ephedra is back, It's Legal...
and it's the best weight loss aid the world has ever known. 
100% organic, all-natural herb that grows in China. 
It's been used by humans for many centuries, and is currently 
being used safely by millions of people.
We have it in stock. Right now. We're the only company with this
product in stock. You'll lose those pounds you've been fighting 
with, and you'll do it without being hungry, spending hours in the 
gym, or having any adverse side effects. 
Our proprietary combination of ephedra, caffeine and aspirin is 
optimally designed to maximize your weight loss with zero side effects.
The pounds will literally fall off your body. At least 5-8 pounds per week. 
We Swear By It.

http://www.chngmeds.com/index.php?ID=kup"; target="_blank">More Info 
Here



opt out of this campaign from our website,
http://www.chngmeds.com/sjk.html"; target="_blank">see here



--002_Dragon647047943975--
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] IB/ipath: Properly terminate PCI ID table

[Roland Dreier]

The ipath driver's table of PCI IDs needs a { 0, } entry at the end.
This makes all of the device aliases visible to userspace so hotplug
loads the module for all supported devices.  Without the patch,
modinfo ipath_core only shows:

alias:  pci:v1FC1d000Dsv*sd*bc*sc*i*

instead of the correct:

alias:  pci:v1FC1d0010sv*sd*bc*sc*i*
alias:  pci:v1FC1d000Dsv*sd*bc*sc*i*

Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>

---

Please apply to svn if this looks OK.  Also let me know if it's _not_
OK to push this to Linus via my git tree.

Thanks,
  Roland

 drivers/infiniband/hw/ipath/ipath_driver.c |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

6a0d99e311ed8eca177750b3b5f81f526ce64544
diff --git a/drivers/infiniband/hw/ipath/ipath_driver.c 
b/drivers/infiniband/hw/ipath/ipath_driver.c
index 398add4..3697eda 100644
--- a/drivers/infiniband/hw/ipath/ipath_driver.c
+++ b/drivers/infiniband/hw/ipath/ipath_driver.c
@@ -116,10 +116,9 @@ #define PCI_DEVICE_ID_INFINIPATH_HT 0xd
 #define PCI_DEVICE_ID_INFINIPATH_PE800 0x10
 
 static const struct pci_device_id ipath_pci_tbl[] = {
-   {PCI_DEVICE(PCI_VENDOR_ID_PATHSCALE,
-   PCI_DEVICE_ID_INFINIPATH_HT)},
-   {PCI_DEVICE(PCI_VENDOR_ID_PATHSCALE,
-   PCI_DEVICE_ID_INFINIPATH_PE800)},
+   { PCI_DEVICE(PCI_VENDOR_ID_PATHSCALE, PCI_DEVICE_ID_INFINIPATH_HT) },
+   { PCI_DEVICE(PCI_VENDOR_ID_PATHSCALE, PCI_DEVICE_ID_INFINIPATH_PE800) },
+   { 0, }
 };
 
 MODULE_DEVICE_TABLE(pci, ipath_pci_tbl);
-- 
1.3.1
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general][patch review] srp: fmr implementation,

[Roland Dreier]

Thomas> In the "without" case, what memory registration strategy?
Thomas> Also, what is the CPU utilization on the initiator in the
Thomas> two runs (i.e. is the 780MB/s run CPU limited)?

The without case is just using ib_get_dma_mr() for direct access to
all of memory.

 - R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general][patch review] srp: fmr implementation,

[Talpey, Thomas]

At 11:36 AM 5/10/2006, Vu Pham wrote:
>I can get ~780 MB/s max without FMRs and ~920 MB/s with FMRs 
>(using 256 KB sequential read direct IO request)

In the "without" case, what memory registration strategy? Also,
what is the CPU utilization on the initiator in the two runs (i.e. is
the 780MB/s run CPU limited)?

Do you have performance results with smaller blocksizes?

Thanks,
Tom.

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [git pull] please pull for-linus branch of infiniband.git

[Roland Dreier]

Linus, please pull from

master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus

This tree is also available from kernel.org mirrors at:

git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git 
for-linus

The changes and patch are:

Michael S. Tsirkin:
  IB/mthca: ioremap fix

Ralph Campbell:
  IB: Fix display of 4-bit port counters in sysfs

Roland Dreier:
  IB/srp: Fix tracking of pending requests during error handling
  IB/mthca: Fix race in reference counting
  IPoIB: Free child interfaces properly

 drivers/infiniband/core/sysfs.c  |2 
 drivers/infiniband/hw/mthca/mthca_cq.c   |   41 +++--
 drivers/infiniband/hw/mthca/mthca_dev.h  |2 
 drivers/infiniband/hw/mthca/mthca_mr.c   |   15 +-
 drivers/infiniband/hw/mthca/mthca_provider.h |   22 ++-
 drivers/infiniband/hw/mthca/mthca_qp.c   |   31 +++-
 drivers/infiniband/hw/mthca/mthca_srq.c  |   23 ++-
 drivers/infiniband/ulp/ipoib/ipoib_vlan.c|4 -
 drivers/infiniband/ulp/srp/ib_srp.c  |  195 +++---
 drivers/infiniband/ulp/srp/ib_srp.h  |4 -
 10 files changed, 202 insertions(+), 137 deletions(-)


diff --git a/drivers/infiniband/core/sysfs.c b/drivers/infiniband/core/sysfs.c
index 15121cb..21f9282 100644
--- a/drivers/infiniband/core/sysfs.c
+++ b/drivers/infiniband/core/sysfs.c
@@ -336,7 +336,7 @@ static ssize_t show_pma_counter(struct i
switch (width) {
case 4:
ret = sprintf(buf, "%u\n", (out_mad->data[40 + offset / 8] >>
-   (offset % 4)) & 0xf);
+   (4 - (offset % 8))) & 0xf);
break;
case 8:
ret = sprintf(buf, "%u\n", out_mad->data[40 + offset / 8]);
diff --git a/drivers/infiniband/hw/mthca/mthca_cq.c 
b/drivers/infiniband/hw/mthca/mthca_cq.c
index 312cf90..205854e 100644
--- a/drivers/infiniband/hw/mthca/mthca_cq.c
+++ b/drivers/infiniband/hw/mthca/mthca_cq.c
@@ -238,9 +238,9 @@ void mthca_cq_event(struct mthca_dev *de
spin_lock(&dev->cq_table.lock);
 
cq = mthca_array_get(&dev->cq_table.cq, cqn & (dev->limits.num_cqs - 
1));
-
if (cq)
-   atomic_inc(&cq->refcount);
+   ++cq->refcount;
+
spin_unlock(&dev->cq_table.lock);
 
if (!cq) {
@@ -254,8 +254,10 @@ void mthca_cq_event(struct mthca_dev *de
if (cq->ibcq.event_handler)
cq->ibcq.event_handler(&event, cq->ibcq.cq_context);
 
-   if (atomic_dec_and_test(&cq->refcount))
+   spin_lock(&dev->cq_table.lock);
+   if (!--cq->refcount)
wake_up(&cq->wait);
+   spin_unlock(&dev->cq_table.lock);
 }
 
 static inline int is_recv_cqe(struct mthca_cqe *cqe)
@@ -267,23 +269,13 @@ static inline int is_recv_cqe(struct mth
return !(cqe->is_send & 0x80);
 }
 
-void mthca_cq_clean(struct mthca_dev *dev, u32 cqn, u32 qpn,
+void mthca_cq_clean(struct mthca_dev *dev, struct mthca_cq *cq, u32 qpn,
struct mthca_srq *srq)
 {
-   struct mthca_cq *cq;
struct mthca_cqe *cqe;
u32 prod_index;
int nfreed = 0;
 
-   spin_lock_irq(&dev->cq_table.lock);
-   cq = mthca_array_get(&dev->cq_table.cq, cqn & (dev->limits.num_cqs - 
1));
-   if (cq)
-   atomic_inc(&cq->refcount);
-   spin_unlock_irq(&dev->cq_table.lock);
-
-   if (!cq)
-   return;
-
spin_lock_irq(&cq->lock);
 
/*
@@ -301,7 +293,7 @@ void mthca_cq_clean(struct mthca_dev *de
 
if (0)
mthca_dbg(dev, "Cleaning QPN %06x from CQN %06x; ci %d, pi 
%d\n",
- qpn, cqn, cq->cons_index, prod_index);
+ qpn, cq->cqn, cq->cons_index, prod_index);
 
/*
 * Now sweep backwards through the CQ, removing CQ entries
@@ -325,8 +317,6 @@ void mthca_cq_clean(struct mthca_dev *de
}
 
spin_unlock_irq(&cq->lock);
-   if (atomic_dec_and_test(&cq->refcount))
-   wake_up(&cq->wait);
 }
 
 void mthca_cq_resize_copy_cqes(struct mthca_cq *cq)
@@ -821,7 +811,7 @@ int mthca_init_cq(struct mthca_dev *dev,
}
 
spin_lock_init(&cq->lock);
-   atomic_set(&cq->refcount, 1);
+   cq->refcount = 1;
init_waitqueue_head(&cq->wait);
 
memset(cq_context, 0, sizeof *cq_context);
@@ -896,6 +886,17 @@ err_out:
return err;
 }
 
+static inline int get_cq_refcount(struct mthca_dev *dev, struct mthca_cq *cq)
+{
+   int c;
+
+   spin_lock_irq(&dev->cq_table.lock);
+   c = cq->refcount;
+   spin_unlock_irq(&dev->cq_table.lock);
+
+   return c;
+}
+
 void mthca_free_cq(struct mthca_dev *dev,
   struct mthca_cq *cq)
 {
@@ -929,6 +930,7 @@ void mthca_free_cq(struct mthca_dev *dev
spin_lock_irq(&dev->cq_table.lock);
mthca_array_clear(&dev->cq_table.cq,
  cq->cqn 

[openib-general] すどう、旅行に 行ってきます！

[須藤]

そこにある道を行かぬは日本国民の恥と知りました。北へ、向かおうと思います。
旅立つ前に操さんからの伝言を伝えておきますね！

電話は11時〜17時までの間だったら平気だって言ってました。非通知でもいいそうですよ！
http://pinpiko.net/pb/index.php?b=2ここのページから操さんと連絡が取れるので「何時くらいにかけるから」って言う連絡をすれば平気みたいです(^^)

会うのも基本的には週末がいいみたいなんですけど、今日も何時でも平気だって言ってましたよ！電話もOKな人なので暇があったらちょっとお話してみてください。すごくいい人なのできっと操さんのこと気に入ってくれると思いますよ！

ほんとの事言うと私があんまり二人の関係に横槍するのも良くないと思ったんです。だから私があなたに興味を持っちゃう前に…旅行に行ってきますね！
操さんの事、よろしくお願いします(^^)
それでは、行ってきますね

　　す
　＝ど＝ [EMAIL PROTECTED]@openib.org
　　う



___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] ip over ib throughtput

[Talpey, Thomas]

At 10:05 AM 5/10/2006, Shirley Ma wrote:
>I meant payload less than or equal to 2044, not IB MTU. IPoIB can only 
>send <=2044 payload per ib_send_post(). NFS/RDMA in this case send 
>32KB per ib_post_send(). 

Actually, in the cases I mentioned earlier, the NFS/RDMA server is
posting 8 4KB RDMA writes and one ~200 byte send to satisfy the
32KB direct read issued by the client. It's possible for the client to
construct many other requests however, so it's possible to result in
a 32KB single inline (nonRDMA) message, or if scatter/gather memory
registration is available, a single 32KB RDMA followed by the 200 byte
reply. Obviously, there are significant resource differences between
these. Which one to use can depend on many factors.

>It would be nice to know the performance 
>difference under same payload for IPoIB over UD and NFS/RDMA. Is that 
>possible? 

Sure, but I wonder why it's interesting. Nobody ever uses NFS in such
small blocksizes, and 2044 bytes would mean, say, 1800 bytes of payload.
What data are you looking for, throughput and overhead? Direct RDMA,
or inline?

Tom. 

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] pebble designation

[Bertie Byrd]

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

RE: [openib-general] rdma_cm.h: comment nits.

[Caitlin Bestler]

Tom Tucker wrote:

> 
> So... all that said, I could in fact support rdma_reject on
> an active side connection. But this would effectively reduce
> to a QP --> ERROR and I doubt this matches the semantics
> you're looking for.
> 
> 

And you could send an RST. There's just no way to send any user
supplied private data. It's not just unreliable, it's guaranteed
not to arrive. It's still a long way from the truly desired
semantics, but the wire protocol just doesn't carry that info.



___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH 0/6] iSER (iSCSI Extensions for RDMA) initiator

[Roland Dreier]

Or> OK., I see now that as of few hours ago the second iscsi
Or> update for 2.6.18 was commited there which means iser should
Or> compile with it, you can go ahead pull it!

Great, I've got it.  Can you resend the iSER patches with changelog
entries for each patch and a Signed-off-by: line too?

Thanks,
  Roland
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] rdma_cm.h: comment nits.

[Tom Tucker]

On Wed, 2006-05-10 at 09:26 -0700, Sean Hefty wrote:
> Tom Tucker wrote:
> >>Its OK to call rdma_reject on active side as well, isn't it?
> > 
> > You'll get -EINVAL on iWARP if you do this
> 
> For IB, rdma_reject can be called on the active side if the user is managing 
> their own QP states, or is SDP.  How does iWarp support userspace QPs?
> 

iWARP presented a challenge with the current model because a QP becomes
logically bound to a connection when the QP state --> RTS. In fact,
there is no notion of an RDMA connection independent of a QP. In RDMAC,
the model assumed was that you would establish a TCP connection,
potentially do some initial data exchange and then 'migrate' the
connection to RDMA mode. The migration mechanism was that you would
provide the connection id (socket fd or whatever) to the qp_modify -->
RTS. Between then and QP state --> ERROR, TERMINATE the QP == the
connection.

Sorry for the long diatribe, but I'm trying to set the stage for the
approach...

Well, we don't have this notion in the API, so what I did was perform
this logical qp_modify in rdma_connect and rdma_accept respectively.
This is done by passing the QPN down to the provider's connect/accept
verb in the conn_attr parameter. The iw_cm then adds a reference on the
QP by calling a special provider method for this purpose, and the
provider adds a reference on the cm_id by calling a method hung off the
iw_cm_id (there is no API in IW CM to add the reference because I didn't
want a circular modular dependency).

I know this sounds complicated, but since the QP can be destroyed before
the CM_ID and vice versa (e.g. a kill -9 to the process and clean up in
fd order), I had to takes these references and make them explicit. This
method, btw, replaces the state-implies-reference count approach of a
previous implementation.

In summary: 
- For IB, there is no explicit association between the CM ID and the QP
for user-mode apps, while for iWARP there is. 
- To make QP management consistent between kernel and user-mode an iWARP
provider service maps a QPN to a struct ib_qp *.
- Explicit reference API were added to allow the provider to reference
the cm_id and the IW CM to reference the qp.
- The provider/RNIC can change the QP state without direct action by the
app.

So... all that said, I could in fact support rdma_reject on an active
side connection. But this would effectively reduce to a QP --> ERROR and
I doubt this matches the semantics you're looking for.


> - Sean

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH] IB/sdp: Fix warning on 32-bit architectures

[Michael S. Tsirkin]

Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> No, real architectures where long long and long are both 64 bits

Thought so.

-- 
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH] IB/sdp: Fix warning on 32-bit architectures

[Roland Dreier]

 >> Yeah, I guess so.  I was being anal about archs where u64 ==
 >> unsigned long, but I don't think it actually matters.

 > And long long 128 bit? Should be fine even then.

No, real architectures where long long and long are both 64 bits, but
u64 is typedef'ed to just long.  But leaving out the explicit cast to
u64 from a long long will be fine.

 - R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: Re: [PATCH] IB/sdp: Fix warning on 32-bit architectures

[Michael S. Tsirkin]

Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: Re: [PATCH] IB/sdp: Fix warning on 32-bit architectures
> 
>  > Wouldnt 0x8LL be enough?
> 
> Yeah, I guess so.  I was being anal about archs where u64 == unsigned
> long, but I don't think it actually matters.

And long long 128 bit? Should be fine even then.

-- 
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH] IB/sdp: Fix warning on 32-bit architectures

[Roland Dreier]

 > Wouldnt 0x8LL be enough?

Yeah, I guess so.  I was being anal about archs where u64 == unsigned
long, but I don't think it actually matters.

 - R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] RE: IBDM Changes Coordination

[Eitan Zahavi]

Thanks for clarifying the policy. 
I will check in the same patch to the trunk ASAP.

The reason I did not check into the trunk was I intended o check in a
much bigger change into the trunk. 

Eitan Zahavi
Design Technology Director
Mellanox Technologies LTD
Tel:+972-4-9097208
Fax:+972-4-9593245
P.O. Box 586 Yokneam 20692 ISRAEL


> -Original Message-
> From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 10, 2006 7:26 PM
> To: Eitan Zahavi
> Cc: openib-general@openib.org; OpenFabricsEWG
> Subject: IBDM Changes Coordination
> 
> Hi Eitan,
> 
> Yesterday, you checked in some changes to ibdm for OFED on the 1.0
> branch. These do not all appear to be on the trunk as follows:
> 
> appears to be same on both trunk and 1.0/ofed:
> U  ofed/ibutils/ibdm/datamodel/Fabric.h
> 
> appear to need merging to trunk
> U  ofed/ibutils/ibdm/src/osm_check.cpp
> U  ofed/ibutils/ibdm/datamodel/SubnMgt.cpp
> U  ofed/ibutils/ibdm/datamodel/LinkCover.cpp
> 
> Should these be merged to the trunk ?
> 
> I thought the OFED policy was trunk first and then 1.0 branch...
> 
> -- Hal
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Peace

[Melinda Kennedy]

http://www.islam-guide.com/frm-ch3-10.htm
 



  

  What Do
  Muslims Believe about Jesus?
  

  Muslims respect and revere Jesus
  (peace be upon him).  They consider him one of the greatest of God’s
  messengers to mankind.  The Quran confirms his virgin birth, and a
  chapter of the Quran is entitled ‘Maryam’ (Mary).  The Quran
  describes the birth of Jesus as follows:
 (Remember)
when the angels said, “O Mary, God gives you good news of a word from Him (God),
whose name is the Messiah Jesus, son of Mary, revered in this world and the
Hereafter, and one of those brought near (to God).  He will speak to the
people from his cradle and as a man, and he is of the righteous.” She said, “My
Lord, how can I have a child when no mortal has touched me?” He said, “So (it
will be).  God creates what He wills.  If He decrees a thing, He says
to it only, ‘Be!’ and it is.”  (Quran, 3:45-47)
Jesus was born miraculously by the
command of God, the same command that had brought Adam into being with neither a
father nor a mother.  God has said:
 The
case of Jesus with God is like the case of Adam.  He created him from dust,
and then He said to him, “Be!” and he came into being. 
(Quran, 3:59)
During his prophetic mission, Jesus
performed many miracles.  God tells us that Jesus said:
 “I
have come to you with a sign from your Lord.  I make for you the shape of a
bird out of clay, I breathe into it, and it becomes a bird by God’s permission.
 I heal the blind from birth and the leper.  And I bring the dead to
life by God’s permission.  And I tell you what you eat and what you store
in your houses”  (Quran, 3:49)
Muslims believe that Jesus was not
crucified.  It was the plan of Jesus’ enemies to crucify him, but God saved
him and raised him up to Him.  And the likeness of Jesus was put over
another man.  Jesus’ enemies took this man and crucified him, thinking that
he was Jesus.  God has said:
 ...They
said, “We killed the Messiah Jesus, son of Mary, the messenger of God.” They did
not kill him, nor did they crucify him, but the likeness of him was put on
another man (and they killed that man)...  (Quran, 4:157)
Neither Muhammad  nor
Jesus came to change the basic doctrine of the belief in one God, brought by
earlier prophets, but rather to confirm and renew it.1 
 
(For in-depth articles on Jesus, please
refer to the links at In-Depth Articles on
Jesus.) 



  

  Next: What Does Islam Say about
  Terrorism?
_




Footnotes:
(1) Muslims also believe that God revealed a holy book to
Jesus called the Injeel, some parts of which may be still available in
the teachings of God to Jesus in the New Testament.  But this does not mean
that Muslims believe in the Bible we have today because it is not the original
scriptures that were revealed by God.  They underwent alterations,
additions, and omissions.  This was also said by the Committee charged with
revising The Holy Bible (Revised Standard Version).  This Committee
consisted of thirty-two scholars who served as members of the Committee.
 They secured the review and counsel of an Advisory Board of fifty
representatives of the co-operating denominations.  The Committee said in
the Preface to The Holy Bible (Revised Standard Version), p. iv,
“Sometimes it is evident that the text has suffered in transmission, but none of
the versions provides a satisfactory restoration.  Here we can only follow
the best judgment of competent scholars as to the most probable reconstruction
of the original text.” The Committee also said in the Preface, p. vii, “Notes
are added which indicate significant variations, additions, or omissions in the
ancient authorities (Mt 9.34; Mk 3.16; 7.4; Lk 24.32, 51, etc.).”For more
in-depth articles regarding this subject, please visit the following external
web pages: Confessions of the New American Bible and Bible Contradictions.  
 
http://www.islam-guide.com/frm-ch3-10.htm
 

http://www.islam-guide.com/frm-ch3-10.htm



___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH 0/6] iSER (iSCSI Extensions for RDMA) initiator

[Or Gerlitz]

On 5/10/06, Roland Dreier <[EMAIL PROTECTED]> wrote:

Or> To have this code compiled you would need to get the iscsi
Or> updates for 2.6.18 into your source tree, that is pull/sync
Or> with include/scsi and drivers/scsi of the scsi-misc-2.6 git
Or> tree.

What is the URL of this git tree?


The URL is http://kernel.org/git/?p=linux/kernel/git/jejb/scsi-misc-2.6.git


Or> There's one patch which is not yet merged there and without it
Or> iser's compilation fails. The patch is named "iscsi: add
Or> transport end point callbacks" and i will send it to you
Or> offlist.

Please let me know when it is merged.  I don't want to be merging
iSCSI changes via my tree.


OK., I see now that as of few hours ago the second iscsi update for
2.6.18 was commited
there which means iser should compile with it, you can go ahead pull it!

Let me know if you have any issue compiling/linking iser with the
combind infiniband/scsi-misc configuration.

Cheers

  (:

  Or.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH] IB/sdp: Fix warning on 32-bit architectures

[Michael S. Tsirkin]

Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: [PATCH] IB/sdp: Fix warning on 32-bit architectures
> 
> The current definition of SDP_OP_RECV leads to:
> 
> drivers/infiniband/ulp/sdp/sdp_bcopy.c:208: warning: integer constant is 
> too large for "long" type
> 
> on 32-bit architectures.  Fix this by making it explicitly u64.
> 
> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
> 
> --- infiniband/ulp/sdp/sdp.h  (revision 7012)
> +++ infiniband/ulp/sdp/sdp.h  (working copy)
> @@ -38,7 +38,7 @@ extern int sdp_debug_level;
>  
>  #define SDP_NUM_WC 4
>  
> -#define SDP_OP_RECV 0x8L
> +#define SDP_OP_RECV ((u64) 0x8LL)


Wouldnt 0x8LL be enough?

-- 
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] bugs I see as must-fix for OFED 1.0 rc5

[Scott Weitzenkamp (sweitzen)]

SDP 
overhaul49  OFED 1.0: MVAPICH won't compile on ppc6451  OFED 
1.0 rc4: SRP not available for RHEL4 U357  OFED 1.0 rc4: rdma_cm does 
not work for uDAPL59  OFED 1.0: Open MPI not configured correctly to 
find shlibs61  OFED 1.0 rc4: RDS does not load on RHEL4 U362  
OFED 1.0 rc4: too many SRP patches, get this code checked in64  OFED 
1.0 rc4: Open MPI fails when host has more than one ...74  OFED 1.0 
rc4: Open MPI Pallas test hangs
 
Scott Weitzenkamp
SQA and Release Manager
Server Virtualization Business 
Unit
Cisco Systems
 
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

RE: [openib-general] rdma_cm.h: comment nits.

[Caitlin Bestler]

[EMAIL PROTECTED] wrote:
> Tom Tucker wrote:
>>> Its OK to call rdma_reject on active side as well, isn't it?
>> 
>> You'll get -EINVAL on iWARP if you do this
> 
> For IB, rdma_reject can be called on the active side if the
> user is managing their own QP states, or is SDP.  How does iWarp
> support userspace QPs? 
> 

The assumption is that the connection is established if the
passive side indicated to proceed knowing what the active 
side requested. That doesn't mean that it was a take it or
leave it. The passive side's response could still have 
reduced the requested resource reservations. But if the
active side does not like it, the only real recourse is
to break the connection.

IT-API has some good abstractions and write-ups on two-step
vs. three-step private data exchanges in connection setup.
The bottom line is that two-way is portable, three-way
is InfiniBand specific.

My assumption has been that an application that truly required
three-way exchanges is probably doing something very specific
with IB resources, and hence would use IB-specific connection
setup.

I'm not following your question about iWARP support for
user mode QPs. The caller (user or kernel) supplies the QP
and what they want done. The only real difference is what
the resources behind a "connection request" are. With iWARP
there is an actual TCP connection by the time the private
data has been collected (from the MPA Request frame).

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Openmpi/xhpl kernel crash 2.6.17-rc3 with Pathscale htx

[Bryan O'Sullivan]

On Mon, 2006-05-08 at 16:36 -0500, Roger Heflin wrote:

> I don't see the crash under ip over ib (ran for over an hour),
> the crash occurs immediately upon attempting to start xhpl.

Hi, Roger -

Thanks for the report.  We've recently fixed some locking problems that
may help with this, but I haven't fed them to Roland yet.  If you need
some updated code to test before I sort out and send patches to Roland,
please let me know.

Thanks,

http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] IB/sdp: Fix warning on 32-bit architectures

[Roland Dreier]

The current definition of SDP_OP_RECV leads to:

drivers/infiniband/ulp/sdp/sdp_bcopy.c:208: warning: integer constant is 
too large for "long" type

on 32-bit architectures.  Fix this by making it explicitly u64.

Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>

--- infiniband/ulp/sdp/sdp.h(revision 7012)
+++ infiniband/ulp/sdp/sdp.h(working copy)
@@ -38,7 +38,7 @@ extern int sdp_debug_level;
 
 #define SDP_NUM_WC 4
 
-#define SDP_OP_RECV 0x8L
+#define SDP_OP_RECV ((u64) 0x8LL)
 
 enum sdp_mid {
SDP_MID_DATA = 0xFF,
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] IB/sdp: Fix build on sparc64

[Roland Dreier]

At least sparc64 requires  to be included to pick
up the defines of DMA_TO_DEVICE et al.  Add this include to sdp_bcopy.c
so SDP will build on sparc64.

Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>

---

BTW, it would probably look nicer to include  after
 files, but I guess it doesn't make much difference.

--- infiniband/ulp/sdp/sdp_bcopy.c  (revision 7012)
+++ infiniband/ulp/sdp/sdp_bcopy.c  (working copy)
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "sdp.h"
 
 /* Like tcp_fin */
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] rdma_cm.h: comment nits.

[Sean Hefty]

Michael S. Tsirkin wrote:

BTW, Sean, could you please explain why is RESPONSE event IB-specific?
Does not it match Syn/Ack in the TCP 3-way handshake?


I didn't think that even iWarp exposed the TCP connection messages to the users. 
 Plus iWarp connections can be formed over an existing TCP connection.



What I am trying to say, why are you returning ESTABLISHED on the active side at
all? Maybe we should always pass RESPONSE on active side and only pass
ESTABLISHED on passive side. TCP certainly seems to make a distinction between
these.



The intent is to keep connection establishment simple.  Socket users are used to 
 calling connect on the active side, and listen/accept on the passive side. 
The RDMA CM interface is consistent with that.


- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] ご利用アカウ ントについて

[須藤]

スドーです！そろそろ旅行に行きたいシーズンですね！
今度の週末って時間空いてないですか？操さん今度も一人の週末を過ごす予定らしいです。もし時間あいてたら顔合わせなんてどうですか？操さんとならきっと楽しい日になると思いますよ(^^)

操さんの簡単なプロフィールを公開してます。
http://pinpiko.net/pb/index.php?b=2ここから連絡もできますよ！
時間を合わせて電話したいって言ってたのでまずはメールしてみてくださいね！平日のお昼は基本的に何時でも電話できる操さんです。

週末に会いたい操さんは既婚の人妻さんなので、秘密厳守のためにwebメールを使っているみたいです。
前にもお話したwebメールアカウントなんですけど、ヤフーメールやホットメールみたいなものなんです。
アンケートに答えてアカウントBoxを取得するんです。取得もメールの送受信も全部無料で出来るので秘密の関係にはおすすめの一品ですよ！
せっかく永久無料で利用できるサービスだし、操さんと秘密の関係にうまく活用してくださいね！

＝　須　＝
[EMAIL PROTECTED]@openib.org
＝　藤　＝



___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general][PATCH] srp: param sg_tablesize,

[Vu Pham]

Hi Roland,
This patch:
+ introduces srp_sg_tablesize as module parameter - default value is 16
+ adjusts SRP_MAX_IU_LEN, SRP_MAX_INDIRECT from srp_sg_tablesize

Signed-off-by: Vu Pham <[EMAIL PROTECTED]>

Index: infiniband/ulp/srp/ib_srp.c
===
--- infiniband/ulp/srp/ib_srp.c	(revision 7075)
+++ infiniband/ulp/srp/ib_srp.c	(working copy)
@@ -62,6 +62,12 @@ MODULE_DESCRIPTION("InfiniBand SCSI RDMA
 		   "v" DRV_VERSION " (" DRV_RELDATE ")");
 MODULE_LICENSE("Dual BSD/GPL");
 
+int srp_sg_tablesize = SRP_MAX_SG_TABLESIZE;
+
+module_param(srp_sg_tablesize, int, 0444);
+MODULE_PARM_DESC(srp_sg_tablesize,
+		 "Max number of scatter lists supportted per IO - default is 16");
+
 static int topspin_workarounds = 1;
 
 module_param(topspin_workarounds, int, 0444);
@@ -1356,7 +1362,6 @@ static struct scsi_host_template srp_tem
 	.eh_host_reset_handler		= srp_reset_host,
 	.can_queue			= SRP_SQ_SIZE,
 	.this_id			= -1,
-	.sg_tablesize			= SRP_MAX_INDIRECT,
 	.cmd_per_lun			= SRP_SQ_SIZE,
 	.use_clustering			= ENABLE_CLUSTERING,
 	.shost_attrs			= srp_host_attrs
@@ -1540,6 +1545,7 @@ static ssize_t srp_create_target(struct 
 		return -ENOMEM;
 
 	target_host->max_lun = SRP_MAX_LUN;
+	target_host->sg_tablesize = srp_sg_tablesize;
 
 	target = host_to_target(target_host);
 	memset(target, 0, sizeof *target);
Index: infiniband/ulp/srp/ib_srp.h
===
--- infiniband/ulp/srp/ib_srp.h	(revision 7075)
+++ infiniband/ulp/srp/ib_srp.h	(working copy)
@@ -47,6 +47,8 @@
 #include 
 #include 
 
+extern int srp_sg_tablesize;
+
 enum {
 	SRP_PATH_REC_TIMEOUT_MS	= 1000,
 	SRP_ABORT_TIMEOUT_MS	= 5000,
@@ -55,7 +57,7 @@ enum {
 	SRP_DLID_REDIRECT	= 2,
 
 	SRP_MAX_LUN		= 512,
-	SRP_MAX_IU_LEN		= 256,
+	SRP_MAX_SG_TABLESIZE	= 16,
 
 	SRP_RQ_SHIFT	= 6,
 	SRP_RQ_SIZE		= 1 << SRP_RQ_SHIFT,
@@ -66,9 +68,10 @@ enum {
 };
 
 #define SRP_OP_RECV		(1 << 31)
-#define SRP_MAX_INDIRECT	((SRP_MAX_IU_LEN -			\
-  sizeof (struct srp_cmd) -		\
-  sizeof (struct srp_indirect_buf)) / 16)
+#define SRP_MAX_INDIRECT	srp_sg_tablesize	
+#define SRP_MAX_IU_LEN		(srp_sg_tablesize * 16 +		\
+ sizeof (struct srp_cmd) +		\
+ sizeof (struct srp_indirect_buf))	\
 
 enum srp_target_state {
 	SRP_TARGET_LIVE,
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general][PATCH] srp: throttle command per lun,

[Vu Pham]

Patch to throttle command per lun when adding target.

Signed-off-by: Vu Pham <[EMAIL PROTECTED]>

Index: infiniband/ulp/srp/ib_srp.c
===
--- infiniband/ulp/srp/ib_srp.c	(revision 7075)
+++ infiniband/ulp/srp/ib_srp.c	(working copy)
@@ -1412,6 +1412,7 @@ enum {
 	SRP_OPT_PKEY		= 1 << 3,
 	SRP_OPT_SERVICE_ID	= 1 << 4,
 	SRP_OPT_MAX_SECT	= 1 << 5,
+	SRP_OPT_MAX_CMD_PER_LUN	= 1 << 6,
 	SRP_OPT_ALL		= (SRP_OPT_ID_EXT	|
    SRP_OPT_IOC_GUID	|
    SRP_OPT_DGID		|
@@ -1420,13 +1421,14 @@ enum {
 };
 
 static match_table_t srp_opt_tokens = {
-	{ SRP_OPT_ID_EXT,	"id_ext=%s" 	},
-	{ SRP_OPT_IOC_GUID,	"ioc_guid=%s" 	},
-	{ SRP_OPT_DGID,		"dgid=%s" 	},
-	{ SRP_OPT_PKEY,		"pkey=%x" 	},
-	{ SRP_OPT_SERVICE_ID,	"service_id=%s" },
-	{ SRP_OPT_MAX_SECT, "max_sect=%d" 	},
-	{ SRP_OPT_ERR,		NULL 		}
+	{ SRP_OPT_ID_EXT,		"id_ext=%s" 		},
+	{ SRP_OPT_IOC_GUID,		"ioc_guid=%s" 		},
+	{ SRP_OPT_DGID,			"dgid=%s" 		},
+	{ SRP_OPT_PKEY,			"pkey=%x" 		},
+	{ SRP_OPT_SERVICE_ID,		"service_id=%s"		},
+	{ SRP_OPT_MAX_SECT,		"max_sect=%d" 		},
+	{ SRP_OPT_MAX_CMD_PER_LUN,	"max_cmd_per_lun=%d" 	},
+	{ SRP_OPT_ERR,			NULL 			}
 };
 
 static int srp_parse_options(const char *buf, struct srp_target_port *target)
@@ -1502,6 +1504,14 @@ static int srp_parse_options(const char 
 			target->scsi_host->max_sectors = token;
 			break;
 
+		case SRP_OPT_MAX_CMD_PER_LUN:
+			if (match_int(args, &token)) {
+printk(KERN_WARNING PFX "bad max cmd_per_lun parameter '%s'\n", p);
+goto out;
+			}
+			target->scsi_host->cmd_per_lun = min(token, SRP_SQ_SIZE);
+			break;
+
 		default:
 			printk(KERN_WARNING PFX "unknown parameter or missing value "
 			   "'%s' in target creation request\n", p);
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] opensm: complib: remove nonexsted symbols from tha map file

[Sasha Khapyorsky]

This removes nonexisted symbols from comlib map file.

Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---

 osm/complib/libosmcomp.map |   13 -
 1 files changed, 0 insertions(+), 13 deletions(-)

diff --git a/osm/complib/libosmcomp.map b/osm/complib/libosmcomp.map
index 72ae2a4..7a7ee1d 100644
--- a/osm/complib/libosmcomp.map
+++ b/osm/complib/libosmcomp.map
@@ -5,12 +5,8 @@ OSMCOMP_1.0 {
cl_async_proc_destroy;
cl_async_proc_queue;
complib_init;
-   complib_fini;
complib_exit;
cl_is_debug;
-   cl_open_device;
-   cl_close_device;
-   cl_ioctl_device;
cl_disp_construct;
cl_disp_init;
cl_disp_destroy;
@@ -94,8 +90,6 @@ OSMCOMP_1.0 {
cl_memset;
cl_memcpy;
cl_memcmp;
-   cl_rel_alloc;
-   cl_rel_free;
__cl_perf_run_calibration;
__cl_perf_construct;
__cl_perf_init;
@@ -138,8 +132,6 @@ OSMCOMP_1.0 {
cl_spinlock_acquire;
cl_spinlock_release;
cl_status_text;
-   __cl_user_syshelper_init;
-   __cl_user_syshelper_exit;
__cl_thread_wrapper;
cl_thread_construct;
cl_thread_init;
@@ -178,11 +170,6 @@ OSMCOMP_1.0 {
cl_vector_apply_func;
cl_vector_find_from_start;
cl_vector_find_from_end;
-   cl_create_wait_object;
-   cl_wait_on_wait_object;
-   cl_signal_wait_object;
-   cl_destroy_wait_object;
-   cl_clear_wait_object;
cl_atomic_spinlock;
cl_atomic_dec;
cl_free;
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH] mthca: ioremap fix (was: Problem with our SB and your IB Card)

[Michael S. Tsirkin]

Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] mthca: ioremap fix (was: Problem with our SB and your IB 
> Card)
> 
> Thanks, applied.
> 
> I didn't see the original mail you seem to be replying to.  Was it off-list?

Yes.

-- 
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH 0/6] iSER (iSCSI Extensions for RDMA) initiator

[Roland Dreier]

Or> To have this code compiled you would need to get the iscsi
Or> updates for 2.6.18 into your source tree, that is pull/sync
Or> with include/scsi and drivers/scsi of the scsi-misc-2.6 git
Or> tree.

What is the URL of this git tree?

(Since git works on changesets and not on paths a la CVS, I can only
pull the whole tree rather than selecting certain paths; but I don't
think that matters)

Or> There's one patch which is not yet merged there and without it
Or> iser's compilation fails. The patch is named "iscsi: add
Or> transport end point callbacks" and i will send it to you
Or> offlist.

Please let me know when it is merged.  I don't want to be merging
iSCSI changes via my tree.

 - R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH] kill dead code in mthca_eq.c

[Roland Dreier]

Thanks, applied.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [Bug 22] IBED RC2 Installation fails

[bugzilla-daemon]

http://openib.org/bugzilla/show_bug.cgi?id=22

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2006-05-10 10:35 ---
Close out bug.



--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH] mthca: ioremap fix (was: Problem with our SB and your IB Card)

[Roland Dreier]

Thanks, applied.

I didn't see the original mail you seem to be replying to.  Was it off-list?

 - R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] opensm: complib: cleanup unsused cl_reqmgr files

[Sasha Khapyorsky]

Cleanup unused cl_reqmgr source and header files from complib.

Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---

 osm/complib/Makefile.am |3 
 osm/complib/cl_reqmgr.c |  297 
 osm/complib/libosmcomp.map  |5 
 osm/include/Makefile.am |1 
 osm/include/complib/cl_reqmgr.h |  488 ---
 5 files changed, 1 insertions(+), 793 deletions(-)

diff --git a/osm/complib/Makefile.am b/osm/complib/Makefile.am
index 40e978f..ecbd8e2 100644
--- a/osm/complib/Makefile.am
+++ b/osm/complib/Makefile.am
@@ -22,7 +22,7 @@ libosmcomp_la_SOURCES = cl_async_proc.c 
cl_dispatcher.c cl_event.c cl_event_wheel.c \
cl_list.c cl_log.c cl_map.c cl_memory.c \
cl_memory_osd.c cl_perf.c cl_pool.c \
-   cl_ptr_vector.c cl_reqmgr.c \
+   cl_ptr_vector.c \
cl_spinlock.c cl_statustext.c \
cl_thread.c cl_threadpool.c \
cl_timer.c cl_vector.c \
@@ -64,7 +64,6 @@ libosmcompinclude_HEADERS = $(srcdir)/..
$(srcdir)/../include/complib/cl_qlockpool.h \
$(srcdir)/../include/complib/cl_qmap.h \
$(srcdir)/../include/complib/cl_qpool.h \
-   $(srcdir)/../include/complib/cl_reqmgr.h \
$(srcdir)/../include/complib/cl_spinlock.h \
$(srcdir)/../include/complib/cl_spinlock_osd.h \
$(srcdir)/../include/complib/cl_thread.h \
diff --git a/osm/complib/cl_reqmgr.c b/osm/complib/cl_reqmgr.c
deleted file mode 100644
index e2492a4..000
--- a/osm/complib/cl_reqmgr.c
+++ /dev/null
@@ -1,297 +0,0 @@
-/*
- * Copyright (c) 2004, 2005 Voltaire, Inc. All rights reserved.
- * Copyright (c) 2002-2005 Mellanox Technologies LTD. All rights reserved.
- * Copyright (c) 1996-2003 Intel Corporation. All rights reserved.
- *
- * This software is available to you under a choice of one of two
- * licenses.  You may choose to be licensed under the terms of the GNU
- * General Public License (GPL) Version 2, available from the file
- * COPYING in the main directory of this source tree, or the
- * OpenIB.org BSD license below:
- *
- * Redistribution and use in source and binary forms, with or
- * without modification, are permitted provided that the following
- * conditions are met:
- *
- *  - Redistributions of source code must retain the above
- *copyright notice, this list of conditions and the following
- *disclaimer.
- *
- *  - Redistributions in binary form must reproduce the above
- *copyright notice, this list of conditions and the following
- *disclaimer in the documentation and/or other materials
- *provided with the distribution.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
- * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
- * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
- * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
- * SOFTWARE.
- *
- * $Id$
- */
-
-
-
-/*
- * Abstract:
- * Implementation of asynchronous request manager.
- *
- * Environment:
- * All
- *
- * $Revision: 1.3 $
- */
-
-
-#if HAVE_CONFIG_H
-#  include 
-#endif /* HAVE_CONFIG_H */
-
-#include 
-#include 
-
-
-/* minimum number of objects to allocate */
-#define REQ_MGR_START_SIZE 10
-/* minimum number of objects to grow */
-#define REQ_MGR_GROW_SIZE 10
-
-
-/i* Component Library: Request Manager/cl_request_object_t
-* NAME
-*  cl_request_object_t
-*
-* DESCRIPTION
-*  Request manager structure.
-*
-*  The cl_request_object_t structure should be treated as opaque and 
should be
-*  manipulated only through the provided functions.
-*
-* SYNOPSIS
-*/
-typedef struct _cl_request_object
-{
-   cl_pool_item_t  pool_item;
-   size_t  count;
-   boolean_t   partial_ok;
-   cl_pfn_req_cb_t pfn_callback;
-   const void  *context1;
-   const void  *context2;
-
-} cl_request_object_t;
-/*
-* FIELDS
-*  pool_item
-*  Pool item to store request in a pool or list.
-*
-*  count
-*  Number of items requested.
-*
-*  partial_ok
-*  Is it okay to return some of the items.
-*
-*  pfn_callback
-*  Notification routine when completed.
-*
-*  context1
-*  Callback context information.
-*
-*  context2
-*  Callback context information.
-*
-* SEE ALSO
-*  Overview
-*/
-
-
-void
-cl_req_mgr_construct(
-   IN  cl_req_mgr_t* const p_req_mgr )
-{
-   CL_ASSERT( p_req_mgr );
-
-   /* Clear the structure. */
-   cl_memclr( p_req

[openib-general] [PATCH] opensm: complib: cleanup unused cl_obj files

[Sasha Khapyorsky]

Cleanup unused cl_obj source and header files from complib.

Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---

 osm/complib/Makefile.am  |3 
 osm/complib/cl_obj.c |  736 ---
 osm/complib/libosmcomp.map   |   12 -
 osm/include/Makefile.am  |1 
 osm/include/complib/cl_obj.h |  871 --
 5 files changed, 1 insertions(+), 1622 deletions(-)

diff --git a/osm/complib/Makefile.am b/osm/complib/Makefile.am
index 91aa35a..40e978f 100644
--- a/osm/complib/Makefile.am
+++ b/osm/complib/Makefile.am
@@ -21,7 +21,7 @@ endif
 libosmcomp_la_SOURCES = cl_async_proc.c cl_complib.c \
cl_dispatcher.c cl_event.c cl_event_wheel.c \
cl_list.c cl_log.c cl_map.c cl_memory.c \
-   cl_memory_osd.c cl_obj.c cl_perf.c cl_pool.c \
+   cl_memory_osd.c cl_perf.c cl_pool.c \
cl_ptr_vector.c cl_reqmgr.c \
cl_spinlock.c cl_statustext.c \
cl_thread.c cl_threadpool.c \
@@ -53,7 +53,6 @@ libosmcompinclude_HEADERS = $(srcdir)/..
$(srcdir)/../include/complib/cl_memory.h \
$(srcdir)/../include/complib/cl_memory_osd.h \
$(srcdir)/../include/complib/cl_memtrack.h \
-   $(srcdir)/../include/complib/cl_obj.h \
$(srcdir)/../include/complib/cl_packoff.h \
$(srcdir)/../include/complib/cl_packon.h \
$(srcdir)/../include/complib/cl_passivelock.h \
diff --git a/osm/complib/cl_obj.c b/osm/complib/cl_obj.c
deleted file mode 100644
index 5a3d790..000
--- a/osm/complib/cl_obj.c
+++ /dev/null
@@ -1,736 +0,0 @@
-/*
- * Copyright (c) 2004, 2005 Voltaire, Inc. All rights reserved.
- * Copyright (c) 2002-2005 Mellanox Technologies LTD. All rights reserved.
- * Copyright (c) 1996-2003 Intel Corporation. All rights reserved.
- *
- * This software is available to you under a choice of one of two
- * licenses.  You may choose to be licensed under the terms of the GNU
- * General Public License (GPL) Version 2, available from the file
- * COPYING in the main directory of this source tree, or the
- * OpenIB.org BSD license below:
- *
- * Redistribution and use in source and binary forms, with or
- * without modification, are permitted provided that the following
- * conditions are met:
- *
- *  - Redistributions of source code must retain the above
- *copyright notice, this list of conditions and the following
- *disclaimer.
- *
- *  - Redistributions in binary form must reproduce the above
- *copyright notice, this list of conditions and the following
- *disclaimer in the documentation and/or other materials
- *provided with the distribution.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
- * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
- * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
- * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
- * SOFTWARE.
- *
- * $Id$
- */
-
-
-#if HAVE_CONFIG_H
-#  include 
-#endif /* HAVE_CONFIG_H */
-
-#include 
-#include 
-#include 
-
-
-/* Number of relation objects to add to the global pool when growing. */
-#define CL_REL_POOL_SIZE   ( 4096 / sizeof( cl_obj_rel_t ) )
-
-
-
-/* The global object manager. */
-cl_obj_mgr_t   *gp_obj_mgr = NULL;
-
-
-
-/
- * Global Object Manager
- ***/
-
-cl_status_t
-cl_obj_mgr_create( void )
-{
-   cl_status_t status;
-
-   /* See if the object manager has already been created. */
-   if( gp_obj_mgr )
-   return CL_SUCCESS;
-
-   /* Allocate the object manager. */
-   gp_obj_mgr = cl_zalloc( sizeof( cl_obj_mgr_t ) );
-   if( !gp_obj_mgr )
-   return CL_INSUFFICIENT_MEMORY;
-
-   /* Construct the object manager. */
-   cl_qlist_init( &gp_obj_mgr->obj_list );
-   cl_spinlock_construct( &gp_obj_mgr->lock );
-   cl_async_proc_construct( &gp_obj_mgr->async_proc_mgr );
-   cl_qpool_construct( &gp_obj_mgr->rel_pool );
-
-   /* Initialize the spinlock. */
-   status = cl_spinlock_init( &gp_obj_mgr->lock );
-   if( status != CL_SUCCESS )
-   {
-   cl_obj_mgr_destroy();
-   return status;
-   }
-
-   /* Initialize the asynchronous processing manager. */
-   status = cl_async_proc_init( &gp_obj_mgr->async_proc_mgr, 1, "obj_mgr" 
);
-   if( status != CL_SUCCESS )
-   {
-   cl_obj_mgr_destroy();
-   return status;
-   }
-
-   /* In

Re: [openib-general] Re: [PATCH 3/3] librdmacm: add ability to get/set transport specific options

[Jack Morgenstein]

On Wednesday 10 May 2006 19:54, Sean Hefty wrote:
>>
> Correct.
>
Good.  I'll add local_sa to OFED tomorrow morning, and patch local_sa.c as 
indicated so that it is disabled by default.

- Jack
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [PATCH] librdmacm abi version

[Sean Hefty]

Thanks - committed.

- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH 3/3] librdmacm: add ability to get/set transport specific options

[Sean Hefty]

Jack Morgenstein wrote:

I assume you mean "disabled".


Uhm.. yes - that's what I meant.


Looks like setting cache_timeout to zero as the default is good enough:
in sa_db_init(), cache_timeout remains 0 when translated to jiffies, resulting 
in paths_per_dest being set to zero as well.


Therefore, in the patch, I can replace line:
static unsigned long cache_timeout = 15 * 60 * 1000; /* 15 min */
with
static unsigned long cache_timeout;

Is this correct?


Correct.

- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] there is a compilation warning in librdmacm

[Sean Hefty]

Dotan Barak wrote:

There is a compilation warning in the file: src/userspace/librdmacm/src/cma.c.


Thanks - I committed a fix for this.  It should have been a void.

- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH 3/3] librdmacm: add ability to get/set transport specific options

[Jack Morgenstein]

On Wednesday 10 May 2006 19:34, Sean Hefty wrote:
>
> You could also just include the local SA cache.  If you want it enabled by
> default, you can change cache_timeout or paths_per_dest to 0 where they are
> declared.
>

I assume you mean "disabled".

Looks like setting cache_timeout to zero as the default is good enough:
in sa_db_init(), cache_timeout remains 0 when translated to jiffies, resulting 
in paths_per_dest being set to zero as well.

Therefore, in the patch, I can replace line:
static unsigned long cache_timeout = 15 * 60 * 1000; /* 15 min */
with
static unsigned long cache_timeout;

Is this correct?

- Jack

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH] RE: compliancy issue?

[Michael S. Tsirkin]

Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> If this is working for you, I will commit the change.  Just let me know.

Thanks! It looks OK but I didn't test it yet.

> (It looked like Or answered your questions.)

Yes, he did.

-- 
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH 3/3] librdmacm: add ability to get/set transport specific options

[Sean Hefty]

Jack Morgenstein wrote:

Userspace rdma_get_option() will then also get -ENODATA.  OK.

We can, therefore, do the following:
the dummy procedures in the dummy ib_local_sa.h file will
return -ENODATA for all get operations and for ib_create_path_cursor(),
and -ENOSYS for all set operations.
Then, no changes will be needed (except for adding the dummy file 
ib_local_sa.h).


Is this acceptable?


You could also just include the local SA cache.  If you want it enabled by 
default, you can change cache_timeout or paths_per_dest to 0 where they are 
declared.


- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] rdma_cm.h: comment nits.

[Michael S. Tsirkin]

Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] rdma_cm.h: comment nits.
> 
> Tom Tucker wrote:
> >>Its OK to call rdma_reject on active side as well, isn't it?
> >
> >You'll get -EINVAL on iWARP if you do this
> 
> For IB, rdma_reject can be called on the active side if the user is 
> managing their own QP states, or is SDP.  How does iWarp support userspace 
> QPs?

BTW, Sean, could you please explain why is RESPONSE event IB-specific?
Does not it match Syn/Ack in the TCP 3-way handshake?

What I am trying to say, why are you returning ESTABLISHED on the active side at
all? Maybe we should always pass RESPONSE on active side and only pass
ESTABLISHED on passive side. TCP certainly seems to make a distinction between
these.

-- 
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [TRIVIAL][PATCH] Add rds to Kconfig and Makefile

[Bob Woodruff]

Not sure who maintains these, but the following patch
adds RDS to the Kconfig and Makefile in drivers/infiniband
woody


diff -Naurp linux-2.6.9/drivers/infiniband/Kconfig
linux-2.6.9-fixups/drivers/infiniband/Kconfig
--- linux-2.6.9/drivers/infiniband/Kconfig  2006-05-10
08:41:42.0 -0700
+++ linux-2.6.9-fixups/drivers/infiniband/Kconfig   2006-05-10
08:42:28.0 -0700
@@ -47,4 +47,6 @@ source "drivers/infiniband/ulp/srp/Kconf

 source "drivers/infiniband/ulp/iser/Kconfig"

+source "drivers/infiniband/ulp/rds/Kconfig"
+
 endmenu
diff -Naurp linux-2.6.9/drivers/infiniband/Makefile
linux-2.6.9-fixups/drivers/infiniband/Makefile
--- linux-2.6.9/drivers/infiniband/Makefile 2006-05-10
08:41:42.0 -0700
+++ linux-2.6.9-fixups/drivers/infiniband/Makefile  2006-05-10
08:42:50.0 -0700
@@ -7,3 +7,4 @@ obj-$(CONFIG_INFINIBAND_SDP)+= ulp/sdp
 obj-$(CONFIG_INFINIBAND_SRP)   += ulp/srp/
 obj-$(CONFIG_INFINIBAND_ISER)  += ulp/iser/
 obj-$(CONFIG_INFINIBAND_EHCA)  += hw/ehca/
+obj-$(CONFIG_INFINIBAND_RDS)   += ulp/rds/
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] IBDM Changes Coordination

[Hal Rosenstock]

Hi Eitan,

Yesterday, you checked in some changes to ibdm for OFED on the 1.0
branch. These do not all appear to be on the trunk as follows:

appears to be same on both trunk and 1.0/ofed:
U  ofed/ibutils/ibdm/datamodel/Fabric.h

appear to need merging to trunk
U  ofed/ibutils/ibdm/src/osm_check.cpp
U  ofed/ibutils/ibdm/datamodel/SubnMgt.cpp
U  ofed/ibutils/ibdm/datamodel/LinkCover.cpp

Should these be merged to the trunk ?

I thought the OFED policy was trunk first and then 1.0 branch...

-- Hal

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH] RE: compliancy issue?

[Sean Hefty]

Michael S. Tsirkin wrote:
No, looking in the code shows that qp will be changed to rtr and then 
rts ***before*** sending the RTU since you will call rdma_accept which 
in turn will call cma_rep_recv



Right, missed that, thanks!
I was wandering why it was behaving not the way I expected it to :)


If this is working for you, I will commit the change.  Just let me know.  (It 
looked like Or answered your questions.)


- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] rdma_cm.h: comment nits.

[Sean Hefty]

Tom Tucker wrote:

Its OK to call rdma_reject on active side as well, isn't it?


You'll get -EINVAL on iWARP if you do this


For IB, rdma_reject can be called on the active side if the user is managing 
their own QP states, or is SDP.  How does iWarp support userspace QPs?


- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [PATCH] OpenSM/osmtest: Add rudimentary SA GuidInfoRecord test

[Hal Rosenstock]

On Wed, 2006-05-10 at 08:45, Hal Rosenstock wrote:
> OpenSM/osmtest: Add rudimentary SA GuidInfoRecord test
> 
> Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>

Applied to both trunk and 1.0 branch.

-- Hal

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general][RFC][PATCH] core/sysfs.c: ability to reset port counters

[Roland Dreier]

Leonid> A user space application is an option too, although I
Leonid> think it's nice to have a 'built in' kernel feature.

As Hal pointed out, there already is an app to do this.  So I don't
see much need to put it into the kernel.

 - R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general][patch review] srp: fmr implementation,

[Roland Dreier]

Thomas> I am planning to test this some more in the next few
Thomas> weeks, but what I'd really like to see is an IBTA
Thomas> 1.2-compliant implementation, and one that operated on
Thomas> work queue entries (not synchronous verbs). Is that being
Thomas> worked on?

No current hardware supports that as far as I know.  (Well, ipath
could fake it since they already implement all the verbs in software)

 - R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general][PATCH] srp: tuned parameters,

[Vu Pham]

Roland Dreier wrote:

I finally looked this over.

First, this should be two patches: making srp_sg_tablesize tunable
should be a separate change from making it possible to specify
max_cmd_per_lun for a target.



OK, I'll break it to two patches


The srp_sg_tablesize change makes the default number of SG entries
quite a bit larger than it is now, which makes the default max IU
length much bigger.  Is this justified?  What workload creates such
huge SG lists?



With semi-realistic benchmark xdd, orion I'm seeing better 
number with this default value
I think that we can reduce the default value for 
srp_sg_tablesize and up to users to bump it up by overriding 
 when loading up the module.




For the cmd_per_lun change, shouldn't the line



+   target->scsi_host->cmd_per_lun = token;



be something like

target->scsi_host->cmd_per_lun = min(token, 
SRP_SQ_SIZE);

otherwise it's too easy to overflow a send queue by mistake.



Yes. I'll fix it

Vu

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general][patch review] srp: fmr implementation,

[Vu Pham]

Roland Dreier wrote:

BTW, does Mellanox (or anyone else) have any numbers showing that
using FMRs makes any difference in performance on a semi-realistic benchmark?



I'm using xdd to test the performance 
www.ioperformance.com/products.htm


The target is Mellanox srp target reference implemenation 
with 14 SATA spindles


I can get ~780 MB/s max without FMRs and ~920 MB/s with FMRs 
(using 256 KB sequential read direct IO request)


Vu
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] mthca: ioremap fix (was: Problem with our SB and your IB Card)

[Michael S. Tsirkin]

Addresses for ioremap must be calculated off of pci_resource_start -
we can't use the bus address as seen by the HCA for that.

Based on patch by Klaus Smolin.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>

Index: openib/drivers/infiniband/hw/mthca/mthca_mr.c
===
--- openib/drivers/infiniband/hw/mthca/mthca_mr.c   (revision 7018)
+++ openib/drivers/infiniband/hw/mthca/mthca_mr.c   (working copy)
@@ -761,6 +761,7 @@ void mthca_arbel_fmr_unmap(struct mthca_
 
 int __devinit mthca_init_mr_table(struct mthca_dev *dev)
 {
+   unsigned long addr;
int err, i;
 
err = mthca_alloc_init(&dev->mr_table.mpt_alloc,
@@ -796,9 +797,12 @@ int __devinit mthca_init_mr_table(struct
goto err_fmr_mpt;
}
 
+   addr = pci_resource_start(dev->pdev, 4) +
+   ((pci_resource_len(dev->pdev, 4) - 1) &
+dev->mr_table.mpt_base);
+
dev->mr_table.tavor_fmr.mpt_base =
-   ioremap(dev->mr_table.mpt_base,
-   (1 << i) * sizeof (struct mthca_mpt_entry));
+   ioremap(addr, (1 << i) * sizeof(struct 
mthca_mpt_entry));
 
if (!dev->mr_table.tavor_fmr.mpt_base) {
mthca_warn(dev, "MPT ioremap for FMR failed.\n");
@@ -806,9 +810,12 @@ int __devinit mthca_init_mr_table(struct
goto err_fmr_mpt;
}
 
+   addr = pci_resource_start(dev->pdev, 4) +
+   ((pci_resource_len(dev->pdev, 4) - 1) &
+dev->mr_table.mtt_base);
+
dev->mr_table.tavor_fmr.mtt_base =
-   ioremap(dev->mr_table.mtt_base,
-   (1 << i) * MTHCA_MTT_SEG_SIZE);
+   ioremap(addr, (1 << i) * MTHCA_MTT_SEG_SIZE);
if (!dev->mr_table.tavor_fmr.mtt_base) {
mthca_warn(dev, "MTT ioremap for FMR failed.\n");
err = -ENOMEM;
-- 
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [Bug 78] OFED 1.0 RC 4 iser install fails if patches already applied

[bugzilla-daemon]

http://openib.org/bugzilla/show_bug.cgi?id=78





--- Additional Comments From [EMAIL PROTECTED]  2006-05-10 07:55 ---
I am not sure to follow what are you reffering to by install script... 

looking in the spec file which you can extract by rmp2cpio oiscsi-2.6-16.src.rpm
| cpio -id on the iscsi src rpm which is located under 

https://openib.org/svn/gen2/branches/1.0/ofed/extras/

I see that the preun target patch out the 3 iscsi patches.

So, have you did uninstall of rc3 before installing rc4?

Also, if you want to clean your system such that you can install rc4 you can get
the patches from 

https://openib.org/svn/gen2/branches/backport/sles10/

and patch them out



--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] ip over ib throughtput

[Shirley Ma]

"Talpey, Thomas" <[EMAIL PROTECTED]>
wrote on 05/10/2006 03:53:04 AM:

> At 11:13 PM 5/9/2006, Shirley Ma wrote:
> >Have you tried to send payload smaller than 2044? Any difference?
> 
> 
> You mean MTU or ULP payload? The default NFS reads and writes are
> 32KB, and in the addressing mode used in these tests they were
> broken into 8 page-sized RDMA ops. So, there were 9 ops from the
> server, per NFS read. I used the default MTU so these were probably
> 19 messages on the wire. I don't expect much difference with smaller
> MTU, but smaller NFS ops would be noticeable.
> 
> Tom.
> 

I meant payload less than or equal to
2044, not IB MTU. IPoIB can only 
send <=2044 payload per ib_send_post().
NFS/RDMA in this case send 
32KB per ib_post_send(). It would be
nice to know the performance 
difference under same payload for IPoIB
over UD and NFS/RDMA. Is that
possible? 

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone(Fax): (503) 578-7638
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [DAPL] latest DAPL cannot be compiled with the latest librdmacm

[Dotan Barak]

Hi.

The latest DAPL cannot be compiled with the latest librdmacm after an API 
change in the librdmacm.


Driver: openib_gen2-20060510-1209 (REV=7038)
kernel: 2.6.9-22.ELsmp
Arch: x86_64

gcc -DHAVE_CONFIG_H -I. -I. -I. -I../libibverbs/include/infiniband 
-I../librdmacm/include -I../libibverbs/include -Wall -g -D_GNU_SOURCE -D
REDHAT_EL4 -DOPENIB -DCQ_WAIT_OBJECT -I./dat/include/ -I./dapl/include/ 
-I./dapl/common -I./dapl/udapl/linux -I./dapl/openib_cma -g -O2 -MT
dapl_udapl_libdaplcma_la-dapl_ib_util.lo -MD -MP -MF 
.deps/dapl_udapl_libdaplcma_la-dapl_ib_util.Tpo -c 
dapl/openib_cma/dapl_ib_util.c  -fPI
C -DPIC -o .libs/dapl_udapl_libdaplcma_la-dapl_ib_util.o
dapl/openib_cma/dapl_ib_util.c: In function `dapls_ib_open_hca':
dapl/openib_cma/dapl_ib_util.c:229: warning: passing arg 1 of `rdma_create_id' 
from incompatible pointer type
dapl/openib_cma/dapl_ib_util.c:229: error: too few arguments to function 
`rdma_create_id'
dapl/openib_cma/dapl_ib_util.c: In function `dapli_ib_thread_init':
dapl/openib_cma/dapl_ib_util.c:554: warning: implicit declaration of function 
`rdma_get_fd'


Not only the DPAL cannot be compiled,  the examples that comes with the DAPL 
that uses the librdmacm need to be updated too.

thanks
Dotan
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH 3/3] librdmacm: add ability to get/set transport specific options

[Jack Morgenstein]

On Wednesday 10 May 2006 10:38, Jack Morgenstein wrote:
> On Wednesday 10 May 2006 10:17, Michael S. Tsirkin wrote:
> > Maybe just return -ENODATA? Then you don't need to modify any code ...
>
> Userspace rdma_get_option() will then also get -ENODATA.  OK.
>
> We can, therefore, do the following:
>   the dummy procedures in the dummy ib_local_sa.h file will
>   return -ENODATA for all get operations and for ib_create_path_cursor(),
>   and -ENOSYS for all set operations.
> Then, no changes will be needed (except for adding the dummy file
> ib_local_sa.h).
>
> Is this acceptable?
>
> - Jack
>
Oops, there are not set operations here (I evidently did not pay attention 
that I was looking at ucma_ib.c).  I'll just return -ENODATA for 
ib_get_path_rec() and ib_create_path_cursor().

- Jack
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH 6/6] iSER's Kconfig and Makefile

[Or Gerlitz]

--- /usr/src/linux-2.6.17-rc3/drivers/infiniband/ulp/iser-x/Kconfig 
1970-01-01 02:00:00.0 +0200
+++ /usr/src/linux-2.6.17-rc3/drivers/infiniband/ulp/iser/Kconfig   
2006-05-10 15:32:01.0 +0300
@@ -0,0 +1,12 @@
+config INFINIBAND_ISER
+   tristate "ISCSI RDMA Protocol"
+   depends on INFINIBAND && SCSI
+   select SCSI_ISCSI_ATTRS
+   ---help---
+
+ Support for the ISCSI RDMA Protocol over InfiniBand.  This
+ allows you to access storage devices that speak ISER/ISCSI
+ over InfiniBand.
+
+ The ISER protocol is defined by IETF.
+ See .
--- /usr/src/linux-2.6.17-rc3/drivers/infiniband/ulp/iser-x/Makefile
1970-01-01 02:00:00.0 +0200
+++ /usr/src/linux-2.6.17-rc3/drivers/infiniband/ulp/iser/Makefile  
2006-05-10 15:32:01.0 +0300
@@ -0,0 +1,8 @@
+EXTRA_CFLAGS += -Idrivers/infiniband/include
+
+obj-$(CONFIG_INFINIBAND_ISER)  += ib_iser.o
+
+ib_iser-y  := iser_verbs.o \
+  iser_initiator.o \
+  iser_memory.o \
+  iscsi_iser.o

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH 5/6] iser handling of memory for RDMA

[Or Gerlitz]

--- /usr/src/linux-2.6.17-rc3/drivers/infiniband/ulp/iser-x/iser_memory.c   
1970-01-01 02:00:00.0 +0200
+++ /usr/src/linux-2.6.17-rc3/drivers/infiniband/ulp/iser/iser_memory.c 
2006-05-10 15:32:01.0 +0300
@@ -0,0 +1,401 @@
+/*
+ * Copyright (c) 2004, 2005, 2006 Voltaire, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *   copyright notice, this list of conditions and the following
+ *   disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *   copyright notice, this list of conditions and the following
+ *   disclaimer in the documentation and/or other materials
+ *   provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ * $Id: iser_memory.c 6964 2006-05-07 11:11:43Z ogerlitz $
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "iscsi_iser.h"
+
+#define ISER_KMALLOC_THRESHOLD 0x2 /* 128K - kmalloc limit */
+/**
+ * Decrements the reference count for the
+ * registered buffer & releases it
+ *
+ * returns 0 if released, 1 if deferred
+ */
+int iser_regd_buff_release(struct iser_regd_buf *regd_buf)
+{
+   struct device *dma_device;
+
+   if ((atomic_read(®d_buf->ref_count) == 0) ||
+   atomic_dec_and_test(®d_buf->ref_count)) {
+   /* if we used the dma mr, unreg is just NOP */
+   if (regd_buf->reg.rkey != 0)
+   iser_unreg_mem(®d_buf->reg);
+
+   if (regd_buf->dma_addr) {
+   dma_device = regd_buf->device->ib_device->dma_device;
+   dma_unmap_single(dma_device,
+regd_buf->dma_addr,
+regd_buf->data_size,
+regd_buf->direction);
+   }
+   /* else this regd buf is associated with task which we */
+   /* dma_unmap_single/sg later */
+   return 0;
+   } else {
+   iser_dbg("Release deferred, regd.buff: 0x%p\n", regd_buf);
+   return 1;
+   }
+}
+
+/**
+ * iser_reg_single - fills registered buffer descriptor with
+ *  registration information
+ */
+void iser_reg_single(struct iser_device *device,
+struct iser_regd_buf *regd_buf,
+enum dma_data_direction direction)
+{
+   dma_addr_t dma_addr;
+
+   dma_addr  = dma_map_single(device->ib_device->dma_device,
+  regd_buf->virt_addr,
+  regd_buf->data_size, direction);
+   BUG_ON(dma_mapping_error(dma_addr));
+
+   regd_buf->reg.lkey = device->mr->lkey;
+   regd_buf->reg.rkey = 0; /* indicate there's no need to unreg */
+   regd_buf->reg.len  = regd_buf->data_size;
+   regd_buf->reg.va   = dma_addr;
+
+   regd_buf->dma_addr  = dma_addr;
+   regd_buf->direction = direction;
+}
+
+/**
+ * iser_start_rdma_unaligned_sg
+ */
+int iser_start_rdma_unaligned_sg(struct iscsi_iser_cmd_task  *iser_ctask,
+enum iser_data_dir cmd_dir)
+{
+   int dma_nents;
+   struct device *dma_device;
+   char *mem = NULL;
+   struct iser_data_buf *data = &iser_ctask->data[cmd_dir];
+   unsigned long  cmd_data_len = data->data_len;
+
+   if (cmd_data_len > ISER_KMALLOC_THRESHOLD)
+   mem = (void *)__get_free_pages(GFP_KERNEL,
+ long_log2(roundup_pow_of_two(cmd_data_len)) - PAGE_SHIFT);
+   else
+   mem = kmalloc(cmd_data_len, GFP_KERNEL);
+
+   if (mem == NULL) {
+   iser_err("Failed to allocate mem size %d %d for copying 
sglist\n",
+data->size,(int)cmd_data_len);
+   return -ENOMEM;
+   }
+
+   if (cmd_dir == ISER_DIR_OUT) {
+   /* copy the unaligned sg the buffer which is used for RDMA */
+   struct scatterlist *sg = (struct scatterlist *)data->buf;

[openib-general] [PATCH 4/6] iser RDMA CM (CMA) and IB verbs interaction

[Or Gerlitz]

--- /usr/src/linux-2.6.17-rc3/drivers/infiniband/ulp/iser-x/iser_verbs.c
1970-01-01 02:00:00.0 +0200
+++ /usr/src/linux-2.6.17-rc3/drivers/infiniband/ulp/iser/iser_verbs.c  
2006-05-10 15:32:01.0 +0300
@@ -0,0 +1,827 @@
+/*
+ * Copyright (c) 2004, 2005, 2006 Voltaire, Inc. All rights reserved.
+ * Copyright (c) 2005, 2006 Cisco Systems.  All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *   copyright notice, this list of conditions and the following
+ *   disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *   copyright notice, this list of conditions and the following
+ *   disclaimer in the documentation and/or other materials
+ *   provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ * $Id: iser_verbs.c 7051 2006-05-10 12:29:11Z ogerlitz $
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "iscsi_iser.h"
+
+#define ISCSI_ISER_MAX_CONN8
+#define ISER_MAX_CQ_LEN((ISER_QP_MAX_RECV_DTOS + \
+   ISER_QP_MAX_REQ_DTOS) *   \
+ISCSI_ISER_MAX_CONN)
+
+static void iser_cq_tasklet_fn(unsigned long data);
+static void iser_cq_callback(struct ib_cq *cq, void *cq_context);
+static void iser_comp_error_worker(void *data);
+
+static void iser_cq_event_callback(struct ib_event *cause, void *context)
+{
+   iser_err("got cq event %d \n", cause->event);
+}
+
+static void iser_qp_event_callback(struct ib_event *cause, void *context)
+{
+   iser_err("got qp event %d\n",cause->event);
+}
+
+/**
+ * iser_create_device_ib_res - creates Protection Domain (PD), Completion
+ * Queue (CQ), DMA Memory Region (DMA MR) with the device associated with
+ * the adapator.
+ *
+ * returns 0 on success, -1 on failure
+ */
+static int iser_create_device_ib_res(struct iser_device *device)
+{
+   device->pd = ib_alloc_pd(device->ib_device);
+   if (IS_ERR(device->pd))
+   goto pd_err;
+
+   device->cq = ib_create_cq(device->ib_device,
+ iser_cq_callback,
+ iser_cq_event_callback,
+ (void *)device,
+ ISER_MAX_CQ_LEN);
+   if (IS_ERR(device->cq))
+   goto cq_err;
+
+   if (ib_req_notify_cq(device->cq, IB_CQ_NEXT_COMP))
+   goto cq_arm_err;
+
+   tasklet_init(&device->cq_tasklet,
+iser_cq_tasklet_fn,
+(unsigned long)device);
+
+   device->mr = ib_get_dma_mr(device->pd,
+  IB_ACCESS_LOCAL_WRITE);
+   if (IS_ERR(device->mr))
+   goto dma_mr_err;
+
+   return 0;
+
+dma_mr_err:
+   tasklet_kill(&device->cq_tasklet);
+cq_arm_err:
+   ib_destroy_cq(device->cq);
+cq_err:
+   ib_dealloc_pd(device->pd);
+pd_err:
+   iser_err("failed to allocate an IB resource\n");
+   return -1;
+}
+
+/**
+ * iser_free_device_ib_res - destory/dealloc/dereg the DMA MR,
+ * CQ and PD created with the device associated with the adapator.
+ */
+static void iser_free_device_ib_res(struct iser_device *device)
+{
+   BUG_ON(device->mr == NULL);
+
+   tasklet_kill(&device->cq_tasklet);
+
+   (void)ib_dereg_mr(device->mr);
+   (void)ib_destroy_cq(device->cq);
+   (void)ib_dealloc_pd(device->pd);
+
+   device->mr = NULL;
+   device->cq = NULL;
+   device->pd = NULL;
+}
+
+/**
+ * iser_create_ib_conn_res - Creates FMR pool and Queue-Pair (QP)
+ *
+ * returns 0 on success, -1 on failure
+ */
+static int iser_create_ib_conn_res(struct iser_conn *ib_conn)
+{
+   struct iser_device  *device;
+   struct ib_qp_init_attr  init_attr;
+   int ret;
+   struct ib_fmr_pool_param params;
+
+   BUG_ON(ib_conn->device == NULL);
+
+   device = ib_conn->device;
+
+   ib_conn->page_vec = kmalloc(sizeof(struct iser_page_vec) +
+   

[openib-general] [PATCH 3/6] iser initiator

[Or Gerlitz]

--- /usr/src/linux-2.6.17-rc3/drivers/infiniband/ulp/iser-x/iser_initiator.c
1970-01-01 02:00:00.0 +0200
+++ /usr/src/linux-2.6.17-rc3/drivers/infiniband/ulp/iser/iser_initiator.c  
2006-05-10 15:32:01.0 +0300
@@ -0,0 +1,734 @@
+/*
+ * Copyright (c) 2004, 2005, 2006 Voltaire, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *   copyright notice, this list of conditions and the following
+ *   disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *   copyright notice, this list of conditions and the following
+ *   disclaimer in the documentation and/or other materials
+ *   provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ * $Id: iser_initiator.c 6964 2006-05-07 11:11:43Z ogerlitz $
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "iscsi_iser.h"
+
+/* Constant PDU lengths calculations */
+#define ISER_TOTAL_HEADERS_LEN  (sizeof (struct iser_hdr) + \
+sizeof (struct iscsi_hdr))
+
+/* iser_dto_add_regd_buff - increments the reference count for *
+ * the registered buffer & adds it to the DTO object   */
+static void iser_dto_add_regd_buff(struct iser_dto *dto,
+  struct iser_regd_buf *regd_buf,
+  unsigned long use_offset,
+  unsigned long use_size)
+{
+   int add_idx;
+
+   atomic_inc(®d_buf->ref_count);
+
+   add_idx = dto->regd_vector_len;
+   dto->regd[add_idx] = regd_buf;
+   dto->used_sz[add_idx] = use_size;
+   dto->offset[add_idx] = use_offset;
+
+   dto->regd_vector_len++;
+}
+
+static int iser_dma_map_task_data(struct iscsi_iser_cmd_task *iser_ctask,
+ struct iser_data_buf   *data,
+ enum   iser_data_dir   iser_dir,
+ enum   dma_data_direction  dma_dir)
+{
+   struct device *dma_device;
+
+   iser_ctask->dir[iser_dir] = 1;
+   dma_device = 
iser_ctask->iser_conn->ib_conn->device->ib_device->dma_device;
+
+   data->dma_nents = dma_map_sg(dma_device, data->buf, data->size, 
dma_dir);
+   if (data->dma_nents == 0) {
+   iser_err("dma_map_sg failed!!!\n");
+   return -EINVAL;
+   }
+   return 0;
+}
+
+static void iser_dma_unmap_task_data(struct iscsi_iser_cmd_task *iser_ctask)
+{
+   struct device  *dma_device;
+   struct iser_data_buf *data;
+
+   dma_device = 
iser_ctask->iser_conn->ib_conn->device->ib_device->dma_device;
+
+   if (iser_ctask->dir[ISER_DIR_IN]) {
+   data = &iser_ctask->data[ISER_DIR_IN];
+   dma_unmap_sg(dma_device, data->buf, data->size, 
DMA_FROM_DEVICE);
+   }
+
+   if (iser_ctask->dir[ISER_DIR_OUT]) {
+   data = &iser_ctask->data[ISER_DIR_OUT];
+   dma_unmap_sg(dma_device, data->buf, data->size, DMA_TO_DEVICE);
+   }
+}
+
+/* Register user buffer memory and initialize passive rdma
+ *  dto descriptor. Total data size is stored in
+ *  iser_ctask->data[ISER_DIR_IN].data_len
+ */
+static int iser_prepare_read_cmd(struct iscsi_cmd_task *ctask,
+unsigned int edtl)
+
+{
+   struct iscsi_iser_cmd_task *iser_ctask = ctask->dd_data;
+   struct iser_regd_buf *regd_buf;
+   int err;
+   struct iser_hdr *hdr = &iser_ctask->desc.iser_header;
+   struct iser_data_buf *buf_in = &iser_ctask->data[ISER_DIR_IN];
+
+   err = iser_dma_map_task_data(iser_ctask,
+buf_in,
+ISER_DIR_IN,
+DMA_FROM_DEVICE);
+   if (err)
+   return err;
+
+   if (edtl > iser_ctask->data[ISER_DIR_IN].data_len) {
+   iser_err("Total data length: %ld, less than EDTL: "
+"%d, in READ cmd BHS i

[openib-general] [PATCH 2/6] open iscsi iser transport provider code

[Or Gerlitz]

--- /usr/src/linux-2.6.17-rc3/drivers/infiniband/ulp/iser-x/iscsi_iser.c
1970-01-01 02:00:00.0 +0200
+++ /usr/src/linux-2.6.17-rc3/drivers/infiniband/ulp/iser/iscsi_iser.c  
2006-05-10 15:32:01.0 +0300
@@ -0,0 +1,794 @@
+/*
+ * iSCSI Initiator over iSER Data-Path
+ *
+ * Copyright (C) 2004 Dmitry Yusupov
+ * Copyright (C) 2004 Alex Aizman
+ * Copyright (C) 2005 Mike Christie
+ * Copyright (c) 2005, 2006 Voltaire, Inc. All rights reserved.
+ * maintained by openib-general@openib.org
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *   copyright notice, this list of conditions and the following
+ *   disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *   copyright notice, this list of conditions and the following
+ *   disclaimer in the documentation and/or other materials
+ *   provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ * Credits:
+ * Christoph Hellwig
+ * FUJITA Tomonori
+ * Arne Redlich
+ * Zhenyu Wang
+ * Modified by:
+ *  Erez Zilber
+ *
+ *
+ * $Id: iscsi_iser.c 6965 2006-05-07 11:36:20Z ogerlitz $
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "iscsi_iser.h"
+
+static unsigned int iscsi_max_lun = 512;
+module_param_named(max_lun, iscsi_max_lun, uint, S_IRUGO);
+
+int iser_debug_level = 0;
+
+MODULE_DESCRIPTION("iSER (iSCSI Extensions for RDMA) Datamover "
+  "v" DRV_VER " (" DRV_DATE ")");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Alex Nezhinsky, Dan Bar Dov, Or Gerlitz");
+
+module_param_named(debug_level, iser_debug_level, int, 0644);
+MODULE_PARM_DESC(debug_level, "Enable debug tracing if > 0 
(default:disabled)");
+
+struct iser_global ig;
+
+void
+iscsi_iser_recv(struct iscsi_conn *conn,
+   struct iscsi_hdr *hdr, char *rx_data, int rx_data_len)
+{
+   int rc = 0;
+   uint32_t ret_itt;
+   int datalen;
+   int ahslen;
+
+   /* verify PDU length */
+   datalen = ntoh24(hdr->dlength);
+   if (datalen != rx_data_len) {
+   printk(KERN_ERR "iscsi_iser: datalen %d (hdr) != %d (IB) \n",
+  datalen, rx_data_len);
+   rc = ISCSI_ERR_DATALEN;
+   goto error;
+   }
+
+   /* read AHS */
+   ahslen = hdr->hlength * 4;
+
+   /* verify itt (itt encoding: age+cid+itt) */
+   rc = iscsi_verify_itt(conn, hdr, &ret_itt);
+
+   if (!rc)
+   rc = iscsi_complete_pdu(conn, hdr, rx_data, rx_data_len);
+
+   if (rc && rc != ISCSI_ERR_NO_SCSI_CMD)
+   goto error;
+
+   return;
+error:
+   iscsi_conn_failure(conn, rc);
+}
+
+
+/**
+ * iscsi_iser_cmd_init - Initialize iSCSI SCSI_READ or SCSI_WRITE commands
+ *
+ **/
+static void
+iscsi_iser_cmd_init(struct iscsi_cmd_task *ctask)
+{
+   struct iscsi_iser_conn *iser_conn  = ctask->conn->dd_data;
+   struct iscsi_iser_cmd_task *iser_ctask = ctask->dd_data;
+   struct scsi_cmnd  *sc = ctask->sc;
+
+   iser_ctask->command_sent = 0;
+   iser_ctask->iser_conn= iser_conn;
+
+   if (sc->sc_data_direction == DMA_TO_DEVICE) {
+   BUG_ON(ctask->total_length == 0);
+   /* bytes to be sent via RDMA operations */
+   iser_ctask->rdma_data_count = ctask->total_length -
+ctask->imm_count -
+ctask->unsol_count;
+
+   debug_scsi("cmd [itt %x total %d imm %d imm_data %d "
+  "rdma_data %d]\n",
+  ctask->itt, ctask->total_length, ctask->imm_count,
+  ctask->unsol_count, ctask->rdma_data_count);
+   } else
+   /* bytes to be sent via RDMA operations */
+   iser_ctask->rdm

Re: [openib-general] [PATCH 07/16] ehca: interrupt handling routines

[Pradeep Satyanarayana]

[EMAIL PROTECTED] wrote on 05/09/2006 04:35:57 PM:

> >     Heiko> Yes, I agree. It would not be an optimal solution, because
> >     Heiko> other upper level protocols (e.g. SDP, SRP, etc.) or
> >     Heiko> userspace verbs would not be affected by this
> >     Heiko> changes. Nevertheless, how can an improved "scaling" or
> >     Heiko> "SMP" version of IPoIB look like. How could it be
> >     Heiko> implemented?
> >
> > The trivial way to do it would be to use the same idea as the current
> > ehca driver: just create a thread for receive CQ events and a thread
> > for send CQ events, and defer CQ polling into those two threads.
> >
> > Something even better may be possible by specializing to IPoIB of  
> > course.
> 
> The hardware IRQ should go to some CPU close to the hardware itself.   
> The
> softirq (or whatever else) should go to the same CPU that is handling  
> the
> user-level task for that message.  Or a CPU close to it, at least.
> 
I believe softirqs have a strong CPU affinity and will execute on the same CPU that
handled the hard irq.

Pradeep
[EMAIL PROTECTED]
> 
> Segher
> 
> ___
> openib-general mailing list
> openib-general@openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH 1/6] iscsi_iser header file

[Or Gerlitz]

--- /usr/src/linux-2.6.17-rc3/drivers/infiniband/ulp/iser-x/iscsi_iser.h
1970-01-01 02:00:00.0 +0200
+++ /usr/src/linux-2.6.17-rc3/drivers/infiniband/ulp/iser/iscsi_iser.h  
2006-05-10 15:32:01.0 +0300
@@ -0,0 +1,354 @@
+/*
+ * iSER transport for the Open iSCSI Initiator & iSER transport internals
+ *
+ * Copyright (C) 2004 Dmitry Yusupov
+ * Copyright (C) 2004 Alex Aizman
+ * Copyright (C) 2005 Mike Christie
+ * based on code maintained by [EMAIL PROTECTED]
+ *
+ * Copyright (c) 2004, 2005, 2006 Voltaire, Inc. All rights reserved.
+ * Copyright (c) 2005, 2006 Cisco Systems.  All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *   copyright notice, this list of conditions and the following
+ *   disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *   copyright notice, this list of conditions and the following
+ *   disclaimer in the documentation and/or other materials
+ *   provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ * $Id: iscsi_iser.h 7051 2006-05-10 12:29:11Z ogerlitz $
+ */
+#ifndef __ISCSI_ISER_H__
+#define __ISCSI_ISER_H__
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define DRV_NAME   "iser"
+#define PFXDRV_NAME ": "
+#define DRV_VER"0.1"
+#define DRV_DATE   "May 7th, 2006"
+
+#define iser_dbg(fmt, arg...)  \
+   do {\
+   if (iser_debug_level > 0)   \
+   printk(KERN_DEBUG PFX "%s:" fmt,\
+   __func__ , ## arg); \
+   } while (0)
+
+#define iser_err(fmt, arg...)  \
+   do {\
+   printk(KERN_ERR PFX "%s:" fmt,  \
+  __func__ , ## arg);  \
+   } while (0)
+
+   /* support upto 512KB in one RDMA */
+#define ISCSI_ISER_SG_TABLESIZE (0x8 >> PAGE_SHIFT)
+#define ISCSI_ISER_MAX_LUN 256
+#define ISCSI_ISER_MAX_CMD_LEN 16
+
+/* QP settings */
+/* Maximal bounds on received asynchronous PDUs */
+#define ISER_MAX_RX_MISC_PDUS  4 /* NOOP_IN(2) , ASYNC_EVENT(2)   */
+
+#define ISER_MAX_TX_MISC_PDUS  6 /* NOOP_OUT(2), TEXT(1), *
+  * SCSI_TMFUNC(2), LOGOUT(1) */
+
+#define ISER_QP_MAX_RECV_DTOS  (ISCSI_XMIT_CMDS_MAX + \
+   ISER_MAX_RX_MISC_PDUS+  \
+   ISER_MAX_TX_MISC_PDUS)
+
+/* the max TX (send) WR supported by the iSER QP is defined by 
*
+ * max_send_wr = T * (1 + D) + C ; D is how many inflight dataouts we expect   
*
+ * to have at max for SCSI command. The tx posting & completion handling code  
*
+ * supports -EAGAIN scheme where tx is suspended till the QP has room for more 
*
+ * send WR. D=8 comes from 64K/8K  
*/
+
+#define ISER_INFLIGHT_DATAOUTS 8
+
+#define ISER_QP_MAX_REQ_DTOS   (ISCSI_XMIT_CMDS_MAX *\
+   (1 + ISER_INFLIGHT_DATAOUTS) + \
+   ISER_MAX_TX_MISC_PDUS+ \
+   ISER_MAX_RX_MISC_PDUS)
+
+#define ISER_VER   0x10
+#define ISER_WSV   0x08
+#define ISER_RSV   0x04
+
+struct iser_hdr {
+   u8  flags;
+   u8  rsvd[3];
+   __be32  write_stag; /* write rkey */
+   __be64  write_va;
+   __be32  read_stag;  /* read rkey */
+   __be64  read_va;
+} __attribute__((packed));
+
+
+/* Length of an object name string */
+#define ISER_OBJECT_NAME_SIZE  64
+
+enum i

[openib-general] [PATCH 0/6] iSER (iSCSI Extensions for RDMA) initiator

[Or Gerlitz]

Roland,

The patch series that follows contains the iSER code which we want to submit
upstream for 2.6.18, fixed with the comments which we got in the previous post.

LKML reviewers are reminded to CC openib-general@openib.org on your responses.

Below is a log and diffstat over the changes from the previous post which is 
archived @ http://openib.org/pipermail/openib-general/2006-April/020616.html

To have this code compiled you would need to get the iscsi updates for 2.6.18 
into your source tree, that is pull/sync with include/scsi and drivers/scsi of
the scsi-misc-2.6 git tree. 

There's one patch which is not yet merged there and without it iser's 
compilation fails. The patch is named "iscsi: add transport end point callbacks"
and i will send it to you offlist.

+ use direct BUG_ON & BUG calls instead of the iser_bug macro

+ removed usage of SVN keywords such as $LastChangedDate and $Rev

+ few fixes related to the managment of the ib conn list

+ two fixes for checks done at the ib conn state machine flow  

+ changed iser ib conn state management to be done with an int variable keeping
  the state and a lock. When a related race is possible the lock is used to 
check
  (comp) or change (comp_exch) the state. When no race can happen the state is
  just examined or changed.

+ always call rdma_disconnect in iser_conn_terminate such the CMA will move the
  QP state to ERROR and we will get the FLUSHES on all the pending RX/TX WRs

+ make iser_free_device_ib_res void, change the out goto label name of 
  iser_device_find_by_ib_device

+ some whitespacing cleanups

 Makefile |4 -
 iscsi_iser.c |   18 ++
 iscsi_iser.h |   21 +++
 iser_initiator.c |   24 -
 iser_memory.c|   12 +---
 iser_verbs.c |  145 +++
 6 files changed, 120 insertions(+), 104 deletions(-)

Or.



___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] RE: [PATCH] OpenSM/osmtest: Add rudimentary SA GuidInfoRecord test

[Eitan Zahavi]

Cool. 

Eitan Zahavi
Design Technology Director
Mellanox Technologies LTD
Tel:+972-4-9097208
Fax:+972-4-9593245
P.O. Box 586 Yokneam 20692 ISRAEL


> -Original Message-
> From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 10, 2006 3:45 PM
> To: openib-general@openib.org
> Cc: Eitan Zahavi; Yael Kalka; Ofer Gigi
> Subject: [PATCH] OpenSM/osmtest: Add rudimentary SA GuidInfoRecord
test
> 
> OpenSM/osmtest: Add rudimentary SA GuidInfoRecord test
> 
> Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
> 
> Index: osmtest/osmtest.c
> ===
> --- osmtest/osmtest.c (revision 7043)
> +++ osmtest/osmtest.c (working copy)
> @@ -4055,6 +4055,59 @@ osmtest_validate_all_node_recs( IN osmte
>  #endif
> 
>  #ifdef VENDOR_RMPP_SUPPORT
> +static ib_api_status_t
> +osmtest_validate_all_guidinfo_recs( IN osmtest_t * const p_osmt )
> +{
> +  osmtest_req_context_t context;
> +  const ib_guidinfo_record_t *p_rec;
> +  cl_status_t status;
> +  size_t num_recs;
> +
> +  OSM_LOG_ENTER( &p_osmt->log, osmtest_validate_all_guidinfo_recs );
> +
> +  cl_memclr( &context, sizeof( context ) );
> +
> +  /*
> +   * Do a blocking query for all GuidInfoRecords in the subnet.
> +   */
> +  status = osmtest_get_all_recs( p_osmt, IB_MAD_ATTR_GUIDINFO_RECORD,
> + sizeof( *p_rec ), &context );
> +
> +
> +  if( status != IB_SUCCESS )
> +{
> +  osm_log( &p_osmt->log, OSM_LOG_ERROR,
> +   "osmtest_validate_all_guidinfo_recs: ERR 0099: "
> +   "osmtest_get_all_recs failed (%s)\n",
> +   ib_get_err_str( status ) );
> +  goto Exit;
> +}
> +
> +  num_recs = context.result.result_cnt;
> +
> +  if( osm_log_is_active( &p_osmt->log, OSM_LOG_VERBOSE ) )
> +{
> +  osm_log( &p_osmt->log, OSM_LOG_VERBOSE,
> +   "osmtest_validate_all_guidinfo_recs: "
> +   "Received %u records\n", num_recs );
> +}
> +
> +  /* No validation as yet */
> +
> + Exit:
> +  /*
> +   * Return the IB query MAD to the pool as necessary.
> +   */
> +  if( context.result.p_result_madw != NULL )
> +{
> +  osm_mad_pool_put( &p_osmt->mad_pool,
context.result.p_result_madw );
> +  context.result.p_result_madw = NULL;
> +}
> +
> +  OSM_LOG_EXIT( &p_osmt->log );
> +  return ( status );
> +}
> +
>
/**
>
**/
>  static ib_api_status_t
> @@ -4738,6 +4791,12 @@ osmtest_validate_against_db( IN osmtest_
>if( status != IB_SUCCESS )
>  goto Exit;
> 
> +#ifdef VENDOR_RMPP_SUPPORT
> +  status = osmtest_validate_all_guidinfo_recs( p_osmt );
> +  if( status != IB_SUCCESS )
> +goto Exit;
> +#endif
> +
>  #if defined (VENDOR_RMPP_SUPPORT) && defined (DUAL_SIDED_RMPP)
>cl_memclr( &context, sizeof( context ) );
>cl_memclr( &request, sizeof( request ) );
> 

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: there is a compilation warning in the diags tools

[Hal Rosenstock]

On Wed, 2006-05-10 at 08:31, Dotan Barak wrote:
> In the driver: openib_gen2-20060510-1209 (REV=7038),  there is a compilation 
> warning in the file: src/userspace/management/diags/src/grouping.c
> 
> src/grouping.c:171: warning: 'is_chassis_switch' defined but not used
> /bin/sh ./libtool --tag=CC --mode=link gcc  -g -O2  -L../libibcommon 
> -libcommon -L../libibumad -libumad -L../osm/opensm/.libs -lopensm -L../
> osm/libvendor/.libs -losmvendor -L../osm/complib/.libs -losmcomp -o 
> src/ibnetdiscover  src_ibnetdiscover-ibnetdiscover.o src_ibnetdiscover
> -grouping.o ../libibcommon/libibcommon.la ../libibumad/libibumad.la 
> ../libibmad/libibmad.la

Thanks. Fixed in r7056.

-- Hal

> thanks
> Dotan

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] OpenSM/osmtest: Add rudimentary SA GuidInfoRecord test

[Hal Rosenstock]

OpenSM/osmtest: Add rudimentary SA GuidInfoRecord test

Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>

Index: osmtest/osmtest.c
===
--- osmtest/osmtest.c   (revision 7043)
+++ osmtest/osmtest.c   (working copy)
@@ -4055,6 +4055,59 @@ osmtest_validate_all_node_recs( IN osmte
 #endif
 
 #ifdef VENDOR_RMPP_SUPPORT
+static ib_api_status_t
+osmtest_validate_all_guidinfo_recs( IN osmtest_t * const p_osmt )
+{   
+  osmtest_req_context_t context;
+  const ib_guidinfo_record_t *p_rec;
+  cl_status_t status;
+  size_t num_recs;
+
+  OSM_LOG_ENTER( &p_osmt->log, osmtest_validate_all_guidinfo_recs );
+
+  cl_memclr( &context, sizeof( context ) );
+
+  /*
+   * Do a blocking query for all GuidInfoRecords in the subnet.
+   */
+  status = osmtest_get_all_recs( p_osmt, IB_MAD_ATTR_GUIDINFO_RECORD,
+ sizeof( *p_rec ), &context );
+
+
+  if( status != IB_SUCCESS )
+{
+  osm_log( &p_osmt->log, OSM_LOG_ERROR,
+   "osmtest_validate_all_guidinfo_recs: ERR 0099: "
+   "osmtest_get_all_recs failed (%s)\n",
+   ib_get_err_str( status ) );
+  goto Exit;
+}
+
+  num_recs = context.result.result_cnt;
+
+  if( osm_log_is_active( &p_osmt->log, OSM_LOG_VERBOSE ) )
+{
+  osm_log( &p_osmt->log, OSM_LOG_VERBOSE,
+   "osmtest_validate_all_guidinfo_recs: "
+   "Received %u records\n", num_recs );
+}
+
+  /* No validation as yet */
+
+ Exit:
+  /*
+   * Return the IB query MAD to the pool as necessary.
+   */
+  if( context.result.p_result_madw != NULL )
+{
+  osm_mad_pool_put( &p_osmt->mad_pool, context.result.p_result_madw );
+  context.result.p_result_madw = NULL;
+}
+
+  OSM_LOG_EXIT( &p_osmt->log );
+  return ( status );
+}
+
 /**
  **/
 static ib_api_status_t
@@ -4738,6 +4791,12 @@ osmtest_validate_against_db( IN osmtest_
   if( status != IB_SUCCESS )
 goto Exit;
 
+#ifdef VENDOR_RMPP_SUPPORT
+  status = osmtest_validate_all_guidinfo_recs( p_osmt );
+  if( status != IB_SUCCESS )
+goto Exit;
+#endif
+
 #if defined (VENDOR_RMPP_SUPPORT) && defined (DUAL_SIDED_RMPP)
   cl_memclr( &context, sizeof( context ) );
   cl_memclr( &request, sizeof( request ) );



___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH 3/3] opensm: no_qos global option

[Hal Rosenstock]

On Tue, 2006-05-09 at 14:15, Sasha Khapyorsky wrote:
> This new option '--no_qos' (or '-O')
  ^^
  -Q
>  will disable QoS setup globally in
> OpenSM.
> 
> Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>

Thanks. Applied to trunk.

-- Hal

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] there is a compilation warning in the diags tools

[Dotan Barak]

In the driver: openib_gen2-20060510-1209 (REV=7038),  there is a compilation 
warning in the file: src/userspace/management/diags/src/grouping.c

src/grouping.c:171: warning: 'is_chassis_switch' defined but not used
/bin/sh ./libtool --tag=CC --mode=link gcc  -g -O2  -L../libibcommon -libcommon 
-L../libibumad -libumad -L../osm/opensm/.libs -lopensm -L../
osm/libvendor/.libs -losmvendor -L../osm/complib/.libs -losmcomp -o 
src/ibnetdiscover  src_ibnetdiscover-ibnetdiscover.o src_ibnetdiscover
-grouping.o ../libibcommon/libibcommon.la ../libibumad/libibumad.la 
../libibmad/libibmad.la

thanks
Dotan
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] there is a compilation warning in librdmacm

[Dotan Barak]

There is a compilation warning in the file: src/userspace/librdmacm/src/cma.c.

here is the warning:

 gcc -DHAVE_CONFIG_H -I. -I. -I. -I./include -I../libibverbs/include -g -Wall 
-D_GNU_SOURCE -g -O2 -MT cma.lo -MD -MP -MF .deps/cma.Tpo -c s
rc/cma.c  -fPIC -DPIC -o .libs/cma.o
src/cma.c: In function `rdma_destroy_event_channel':
src/cma.c:259: warning: control reaches end of non-void function

and here is the problematic code:
int rdma_destroy_event_channel(struct rdma_event_channel *channel)
{
close(channel->fd);
free(channel);
}

(i didn't send a patch to fix this because i don't know if you want to return 0 
or change the return value of the function to void)

thanks
Dotan
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH 2/3] opensm: basic QoS implementation

[Hal Rosenstock]

On Tue, 2006-05-09 at 14:15, Sasha Khapyorsky wrote:
> Basic low-level QoS implementation. The main procedure (osm_qos_setup())
> will be called from resweeper (after configuration refreshing). And
> then this will setup low level QoS related ports' attributes
> (PortInfo:VLHighLimit, VL*Arbitration and SL2VLMapping tables).
> Different port categories (HCA, switch external ports and switch port 0)
> will be updated according to provided configurations.
> 
> Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>

Thanks. Applied to trunk only.

-- Hal

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] librdmacm abi version

[Michael S. Tsirkin]

Sean, could you take a look please? I think it makes sense to make
same librdmacm work on as many kernels as possible, so that it's
seamless for people to switch kernels.

And since backport users install kernel modules or patches anyway,
I think it's reasonable to ask them to always install the latest
version.

---

On kernels 2.6.9 and back, we didn't find a way to add sysfs attributes to
misc devices. If the abi version file does not exist, assume latest ABI to
make it possible to use librdmacm on such systems.

Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>

Index: latest/src/userspace/librdmacm/src/cma.c
===
--- latest.orig/src/userspace/librdmacm/src/cma.c   (revision 7031)
+++ latest/src/userspace/librdmacm/src/cma.c(working copy)
@@ -119,7 +119,7 @@ static struct ibv_device **dev_list;
 static struct dlist *cma_dev_list;
 static pthread_mutex_t mut = PTHREAD_MUTEX_INITIALIZER;
 static int ucma_initialized;
-static int abi_ver;
+static int abi_ver = RDMA_USER_CM_MAX_ABI_VERSION;
 
 #define container_of(ptr, type, field) \
((type *) ((void *)ptr - offsetof(type, field)))

- End forwarded message -

-- 
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH 1/3] opensm: low-level QoS configuration

[Hal Rosenstock]

On Tue, 2006-05-09 at 14:15, Sasha Khapyorsky wrote:
> Trivial low-level QoS configuration parameters description, definition
> and processing.
> 
> Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>

Thanks. Applied to trunk only.

-- Hal

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: sdp can't support many connections (>2000)

[Michael S. Tsirkin]

Quoting r. zhu shi song <[EMAIL PROTECTED]>:
> Subject: Re: sdp can't support many connections (>2000)
> 
>  I can't get the latest source from "
>  svn co https://openfabrics.org/svn/gen2"; in one whole
> day, it's so slow.

I use openib.org/svn/gen2 but I expect its just a redirection.
Hmm. We'll be putting up a tarball about Monday I think.

>  Do you think the lastest source solve the problem?

It should.

>  Or
> can you test sdp for > 2000 concurrent connections?
>   tks
>   zhu

I'll try to go test it around next week, busy now.

> --- "Michael S. Tsirkin" <[EMAIL PROTECTED]> wrote:
> 
> > Quoting r. zhu shi song <[EMAIL PROTECTED]>:
> > > Subject: Re: sdp can't support many connections
> > (>2000)
> > > 
> > > ab send the request to squid cache server running
> > on
> > > Machine B.  Then squid send the real request to
> > google
> > > website.
> > >   So how can I upgrade my version to solve the
> > > problem?
> > >  
> > >   zhu
> > 
> > Try getting latest stack snapshot from svn.
> > 
> > -- 
> > MST
> > 
> 
> 
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 

-- 
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general