[openib-general] The Industries leading enhancement product, now on sale!
Title: Hi dear baby In a trice without warning the face of nature grew sullen Black angry mouths, the clouds swallowed up the sun The air was dense with suppressed excitement The wind howled through the long corridors and sobbed and whispered in the secret recesses of the cells The chime of the Vesper bell flowed out into the infinite The silver notes the holy chant wrestled with the storm like ministering angels with Satan At last the imps of Storm lay vanquished. The hurricane paused in its course to do reverence to God. Suddenly, however a terrific clap of thunder smote the sky The holy chime of the bell broke off with a a shrill dissonance Demons seemed to people the belfry Rain came down like cataract Flashes of lightning chased one another like battling fiery dragons. The bells jangled hideously out of tune Unearthly noises like a satanic parody of the holy sound that marks the elevation of the host alarmed the ears the horrified monks unspeakable blasphemies Prayer with ceremony and interspersed midst of a sacred had suddenly gone mad in the if a High Priest Trembling but resolute Father Ambrose seized a crucifix In phalanx if for battle the brethren followed Solemn, with gleaming eyes and trembling nostrils, the militant army of God swept up steep stairs mumbling the ritual of the Exorcism Infected somewhat by the general hysteria Aubrey followed ___ 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] snsサイトへとリ ニューアルオープン致しました
フリー掲示板からSNS（招待制コミニティー）へとリニューアルオープンしましたのでご連絡さしあげます。 フリー掲示板では皆様からのご意見をもとに改正させて頂き、今月頭より新番組としてオープン致しております。 openib-generalこちらのユーザー様はフリー掲示板の方ですでに登録済みとなっておりましたので変更通知をお送りさせて頂きました。 使用上のポイントとしては完全無料のフリーコミニティとしてお使い頂けます。 コミニティ・ナビから【かおりさん・綾音さん】こちらの3名の方が友ナビとして話すコトができます。 フリー掲示板で行っていました、18禁の書き込み（乱交イベント・アダルトイベント・￥助・逆￥…フェチ画像投稿）などなどこちらもコミニティの方で断続してお使いになれます。 使用料金はいっさい頂きませんが、アダルト掲示板のため任意の上お使いになられてください。 http://hanabira.org/c/new_p.cgi?ix13a 本来、招待制のコミニティですがopenib-generalユーザー様へはすでにご登録いただいておりますのでこちらより変更のお手続きを済ませてください。 もし、見に覚えのないメールでしたらフリー登録を済ませた後、情報をご確認いただけますようお願い致します。 http://hanabira.org/e/new_p.cgi?ix13a こちらは個室コミニティとなっています、 アプローチ待ちの女性が随時更新されるシステムになっていますので、チェックしてみては如何でしょうか!! すべて完全無料のコミニティです! 今現在参加いただいてる会員数は76万人となっています！ リニューアルされたコミニティ！ぜひお使いになられてください。 ___ 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> 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. - 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] RE: SDP fails to compile on SVN6829
Hi,
are there any limitations faced by old SDP implementation, why reimplementation is required?
On 5/1/06, Bob Woodruff <[EMAIL PROTECTED]> wrote:
Michael wrote,> do I need an additional patch or is the backport patch broken ?Personally, I don't think we should be moving code into the trunkuntil it is ready, and obviously this new SDP is not ready.
This is correct code should no be added to the trunk until its not complete.
Anyone else have an opinion on how/when things get moved to the trunk ?Shouldn't it be kept on a branch till it is ready ?
>I think you need these:> A /gen2/branches/backport/2.6.9/linux_skbuff_6754_to_2_6_11.patch (from>/gen2/branches/backport/2.6.11/linux_skbuff_6754_to_2_6_11.patch:6765)For example, this patch adds a function
static inline void skb_header_release(struct sk_buff *skb)that does not do anything yet.Maybe I better wait till you have this newSDP completed before moving to it, until then I will use the olderSDP.
woody===--- /dev/null 1970-01-01 00:00:00.0 ++++ last_stable/include/linux/skbuff.h 2006-04-30 09:16:05.0 +0300
@@ -0,0 +1,19 @@+#ifndef LINUX_SKBUFF_H_BACKPORT+#define LINUX_SKBUFF_H_BACKPORT++#include_next ++/**+ * skb_header_release - release reference to header+ * @skb: buffer to operate on
+ *+ * Drop a reference to the header part of the buffer. This is done+ * by acquiring a payload reference. You must not read from theheader+ * part of skb->data after this.+ */
+static inline void skb_header_release(struct sk_buff *skb)+{+}+++#endifMST___openib-general mailing list
openib-general@openib.orghttp://openib.org/mailman/listinfo/openib-generalTo 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] {úÌz ó]Å·
\x81y\x8Bt\x89\x87\x8F\x95\x8A\xF3\x96]\x83\x81\x81[\x83\x8B1\x8C\x8F\x81z\x93\xCD\x82\xAB\x82\xDC\x82\xB5\x82\xBD\x81B http://twilight.cx/h/ \x81w\x96\xBC\x91O\x81x\x81F\x97R\x8D\x81 \x81w\x94N\x97\xEE\x81x\x81F35\x8D\xCE \x81w\x90E\x8B\xC6\x81x\x81Fｩ\x89c\x8B\xC6 \x81w\x94N\x8E\xFB\x81x\x81F6000\x96\x9C\x89~ \x81w\x89\x87\x8F\x95\x81x\x81F\x8Fo\x97\x88\x82\xDC\x82\xB7 \x81wﾊ\x90^\x81x\x81F\x82\xA0\x82\xE8 \x81w\x93\xE0\x97e\x81x\x81F\x82\xB1\x82\xEA\x82\xA9\x82\xE7\x89\xEF\x82\xA6\x82\xDC\x82\xB7\x82\xA9\x81H \x81w\x88\xEA\x8C\xBE\x81x\x81F\x91\xBD\x82\xAD\x82\xCD\x96]\x82\xDC\x82\xC8\x82\xA2\x82\xCC\x82\xC5\x81A\x8E\x84\x82\xBE\x82\xAF\x82\xCC\x83Z\x83t\x83\x8C\x82\xC9\x82\xC8\x82\xC1\x82\xC4\x82\xAD\x82\xEA\x82\xDC\x82\xB9\x82\xF1\x82\xA9\x81H [EMAIL PROTECTED]@[EMAIL PROTECTED]@\x81@ \x81\x99\x82\xB1\x82\xBF\x82\xE7\x82\xA9\x82\xE7\x96\xB3\x97\xBF\x95\xD4\x90M\x81\x99 http://twilight.cx/h/ \x81\xA6\x8C\xBB\x8D\xDD\x81A\x97R\x8D\x81\x82\xB3\x82\xF1\x82\xA9\x82\xE7\x82\xCC\x8A\xF3\x96]\x83\x81\x81[\x83\x8B\x82\xAA\x92\x85\x82\xC4\x82\xA2\x82\xDC\x82\xB7\x81B \x81\x99yahoo\x83A\x83h\x83\x8C\x83X\x82\xC8\x82\xC7\x83t\x83\x8A\x81[\x83\x81\x81[\x83\x8B\x83A\x83h\x83\x8C\x83X\x82\xA9\x82\xE7\x82\xC5\x82\xE0\x93o\x98^\x82\xC5\x82\xAB\x82\xDC\x82\xB7\x81\x99 \x81\x99\x97R\x8D\x81\x82\xB3\x82\xF1\x82\xA9\x82\xE7\x82\xCC\x8Bt\x89\x87\x8F\x95\x8A\xF3\x96]\x82\xCD\x91\xE5\x95\xCF\x90l\x8BC\x82\xC5\x82\xB7\x82\xCC\x82\xC5\x82\xA8\x91\x81\x96\xDA\x82\xCC\x82\xA8\x95\xD4\x8E\x96\x82\xF0\x82\xA8\x8A\xA9\x82\xDF\x92v\x82\xB5\x82\xDC\x82\xB7\x81B \x81y\x95\xDB\x8F\xD8\x8B\xE0\x81E\x93o\x98^\x81E\x8F\xD0\x89\xEE\x82\xC8\x82\xC7\x91S\x82\xC4\x96\xB3\x97\xBF\x81z ___ 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] Your mortagee approval
scuff a fatima or alia see dunlap it housework may system but start try optometry , frilly try creamery ! cretin on canton it taxied some lutanist try allotropic be darry it's prosper and andrei , thunderous in revocable not polariscope ! serviette and ernie see circumcise try edmonds some watergate on skeletal ! chisel but personify or opinion some hitachi ! robotic see indelible and aristotelian it's Keine email hier try anastomotic a cretinous not some descent a periphery it's , bride see newman try but wont not ax in ___ 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] Problem running mpdboot command in MVAPICH2 v0.9.3-RC0
Albert, Has anything changed with your system since compiling MVAPICH2? I'm a bit confused why it would have worked with 0.9.2 and not 0.9.3-RC0. There wasn't any change between 0.9.2 and 0.9.3-RC0 that should create this type of issue. Can you try re-compiling and re-running? If you could also send along the configure.log generated it may help us look into this issue. Also, can you just send the output from ls -l /usr/local/lib, just to make sure there isn't any problems there? Thanks, Matthew Koop - Network-Based Computing Laboratory Ohio State University > Hi Wei, > > Thanks for a prompt reply. > > Yes, I did originally export the LD_LIBRARY_PATH in .bashrc as followed: > export LD_LIBRARY_PATH=/usr/local/lib > > I've also tried your suggestion: > export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH > > In either case, issue still exists. Given the same setup, I did NOT see > this issue in v0.9.2 (obtained from > https://openib.org/svn/gen2/trunk/src/userspace/mpi/mvapich2-gen2). > > Thanks, > Albert > > Original Message- > From: wei huang [mailto:[EMAIL PROTECTED] > Sent: Saturday, April 29, 2006 2:09 PM > To: Albert To > Cc: openib-general@openib.org > Subject: Re: [openib-general] Problem running mpdboot command in > MVAPICH2 v0.9.3-RC0 > > Hi Albert, > > Not sure if you export /usr/local/lib to LD_LIBRARY_PATH manually or it > is in your bashrc. > > Could you please try to put > export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH > > in your .bashrc (assume using bash) and try again? > > Thanks. > > Regards, > Wei Huang > > 774 Dreese Lab, 2015 Neil Ave, > Dept. of Computer Science and Engineering Ohio State University OH 43210 > Tel: (614)292-8501 > > > On Fri, 28 Apr 2006, Albert To wrote: > > > Hi, > > > > I downloaded and compiled the MVAPICH2 v0.9.3-RC0 using > > make.mvapich2.gen2 script. The script finished without any errors. > > However, I received "mpdboot: error while loading shared libraries: > > libibverbs.so.1: cannot open shared object file: No such file or > > directory" error while executing mpdboot -n 2 -f mpd.hosts. I checked > > > library file libibverbs.so.1 and found it in /usr/local/lib folder. > > LD_LIBRARY_PATH is already set to /usr/local/bin, but that didn't > help. > > > > Is there another environment variable that I need to set to make > > mpdboot works? Thanks in advance for your help. > > > > -Albert > > > > > > ___ > 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] OpenIB Linux and Solaris
Can anybody comment on recent experience regarding inter-operability of OpenIB/Linux on Intel 64 bit x86 and Sparx/Solaris using the Sun stack? Ideally inter-operability would start at IPoIB and the SM but perhaps extend to inter-operable SDP? Has anyone tried porting some userspace low-level OpenIB verbs comms (UC, RDMA write specifically). I am not experienced enough to understand if there are any gotchas with unimplemented features in either the Solaris or OpenIB implementations. I've not had much luck investigating the equivalent of userspace verbs support for Solaris. I notice that some of the commercial stacks offer cross platform support and say 'OpenIB support, Linux, Windows, Solaris and Mac OS X'. I suspect this might be subtle wording as I don't think OpenIB is ported toSolaris, ULP support is using some Solaris 10 drivers instead? Advice/ URL pointers appreciated (Google wasn't my friend!) Paul Baxter ___ 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 2 of 13] ipath - set up 32-bit DMA mask if 64-bit setup fails
Segher> Oh, that. Right. It's about time I get my whole MSI Segher> patch set into shape for submission here, yes. OK, that explains everything ;) So the ipath driver with a PCIe device works on a PowerMac G5? Cool. - 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] Re: [PATCH 2 of 13] ipath - set up 32-bit DMA mask if 64-bit setup fails
Segher> And it builds just fine -- what is the problem you're Segher> thinking of? Well, the ipath driver depends on PCI_MSI, and PCI_MSI depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64 Oh, that. Right. It's about time I get my whole MSI patch set into shape for submission here, yes. So how do you enable the driver? In a very hackish way right now :-( And what powerpc platform can you use the device on? The latest PowerMac's have hardware support for MSI, to name just one platform. 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
Re: [openib-general] Re: [PATCH 2 of 13] ipath - set up 32-bit DMA mask if 64-bit setup fails
Segher> And it builds just fine -- what is the problem you're Segher> thinking of? Well, the ipath driver depends on PCI_MSI, and PCI_MSI depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64 So how do you enable the driver? And what powerpc platform can you use the device on? - 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 2 of 13] ipath - set up 32-bit DMA mask if 64-bit setup fails
Segher> PowerPC with U3 or U4 northbridge, i.e. Maple or PowerMac Segher> G5 systems. If the IOMMU (DART) is disabled, we have a Segher> 32-bit only DMA mask. The DART will be disabled by Segher> default if there is 2GB or less of memory (as it isn't Segher> needed then). OK, thanks. I was not aware of that situation. However, I suspect that PathScale has a different situation in mind, considering that their driver isn't even buildable for that platform ;) Well (a previous version of) that patch came from me, draw your own conclusions :-) And it builds just fine -- what is the problem you're thinking of? 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
Re: [openib-general] ib_srp
Di> Roland, I've never done that before, if it's simple to do, I Di> would be happy to re-run the test and produce the output. Yes, please do. All you need to do is echo "t" > /proc/sysrq-trigger and send the output. The PID of the process that's hanging is useful too. - 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] 来ました
谷原さんから連絡来ました！ほんとに良かった…心配かけちゃって本当にごめんなさい(T-T) なんだか実家の方で色々あって大変だったみたいでちょっと寂しそうでした。 もう彼女の方には連絡してもらえていましたか？谷原さんに聞きのがしちゃって、、けっこう辛そうな感じだったから良かったら後でまた連絡してあげてください。 実家のことでもう2,3日連休もらってるみたいだから、時間が空いてたら一緒にお食事とか誘ってあげたらすごく喜ぶと思います。 谷原さんは外食好きな人で色んなお店知ってるし楽しいと思いますよ(^^) あ、連絡取れてなかったり直接連絡ならhttp://dendeke.net/pb/index.php?b=2から0円でみんな出来るようになりましたから！ 他の人も早く紹介してあげたいし良かったら牧野さんたちにも連絡してあげてくださいね！ 二人とも今日明日なら大丈夫って言ってましたからタイミング的にもよいと思いますよ(^^) 中野杏子([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] Re: [PATCH 2 of 13] ipath - set up 32-bit DMA mask if 64-bit setup fails
Segher> PowerPC with U3 or U4 northbridge, i.e. Maple or PowerMac Segher> G5 systems. If the IOMMU (DART) is disabled, we have a Segher> 32-bit only DMA mask. The DART will be disabled by Segher> default if there is 2GB or less of memory (as it isn't Segher> needed then). OK, thanks. I was not aware of that situation. However, I suspect that PathScale has a different situation in mind, considering that their driver isn't even buildable for that platform ;) - 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] RFC: detecting duplicate MAD requests
On Mon, 2006-05-01 at 14:18, Sean Hefty wrote: > >Aren't there 3 cases possible here: (1) non RMPP request/RMPP response > >(e.g. SA GetTable for one), (2) RMPP request/RMPP response (e.g. SA > >GetMulti), and (3) RMPP request/non RMPP response (I don't think this > >currently exists but may be mistaken). Are all handled on the > >initiator/requester side ? Are the changes only for case (2) ? > > For case 1, we don't have DS RMPP. I think you mean (we have) non DS RMPP. > For case 2, we have DS RMPP. > > And I don't believe that case 3 exists either, but would end up being treated > as > DS RMPP by the implementation. Why ? Just wondering... > If case 3 doesn't exist, then I think we can > come up with a generic way to identify DS RMPP that doesn't require checking > class or methods. How ? > If case 3 does exist, then I think we'll need class / method > checking to identify DS RMPP. By doesn't exist, do you mean not possible in the architecture or no current use cases like this ? -- 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] Re: [PATCH 00/12] SRP: Changing ibsrpdm
Ishai> As I understand it, the path in multipathing is going to be Ishai> part of the attributes of the connection to the target. So Ishai> there will be no problem to add the same target twice, if Ishai> it has a different path leading to it. Yes, that's the usual way to do it. But I don't see why we want to forbid having the same path but multiple local QPs. For example that would allow some intelligent upper layer to implement "storage QoS" by avoiding head-of-line blocking. - 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] ib_srp
Roland, I've never done that before, if it's simple to do, I would be happy to re-run the test and produce the output. Thanks > -Original Message- > From: Roland Dreier [mailto:[EMAIL PROTECTED] > Sent: Monday, May 01, 2006 1:06 PM > To: Di Domenico, Michael > Cc: openib-general@openib.org > Subject: Re: [openib-general] ib_srp > > Di> Hi, Is there a way to remove a target from the SRP > Di> configuration without unloading the driver module (which seems > Di> to have partially removed the disk, but appears to be > Di> hanging)? > > Unloading the module should work. A trace from sysrq-t that shows > where rmmod/modprobe -r is hanging would be useful. > > Right now there isn't a way to disconnect from a particular target > port without unloading the module though. > > - 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] SRP: Avoid a potential deadlock
On Mon, May 01, 2006 at 11:27:24AM -0700, Roland Dreier wrote: > Ishai> Avoid a potential dead-lock. In srp_disconnect_target > Ishai> there is a call to ib_send_cm_dreq and a wait for > Ishai> completion If when getting DREP there is no comp no one > Ishai> will end this wait > > I thought that after the DREP is received, the CM will go through > timewait and we will eventually get a TIMEWAIT_EXIT event (with a > completion). Am I wrong? Have you actually seen this deadlock happen > in practice? > > - R. I had a deadlock and I suspected at this. I'm not sure that it was the reason for the deadlock. Vu, What do you think? -- Ishai Rabinovitz ___ 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 of 13] ipath - set up 32-bit DMA mask if 64-bit setup fails
Bryan> Some systems do not set up 64-bit maps on systems with 2GB
Bryan> or less of memory installed, so we have to fall back to
Bryan> trying a 32-bit setup.
Which systems does this happen on?
PowerPC with U3 or U4 northbridge, i.e. Maple or PowerMac G5 systems.
If the IOMMU (DART) is disabled, we have a 32-bit only DMA mask. The
DART will be disabled by default if there is 2GB or less of memory (as
it isn't needed then).
I'm just curious, because mthca has
err = pci_set_dma_mask(pdev, DMA_64BIT_MASK);
if (err) {
dev_warn(&pdev->dev, "Warning: couldn't set 64-bit PCI DMA mask.
\n");
and I've never had a single report of that warning triggering.
That's only because I never used those cards on systems with fewer
than 4GB of memory :-)
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] Re: Re: [PATCH v2] mad: use GID/LID on requester sidewhen matching responses to requests
Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > Subject: RE: Re: [PATCH v2] mad: use GID/LID on requester sidewhen matching > responses to requests > > >> >Check GID/LID for requester side when searching for request which matches > >> >received response. This, in order to guarantee uniqueness if use same TID > >> >when requesting via multiple source LIDs (when LMC is not zero). To > >> >perform > >> >check, add LMC to cache. > >> > > >> >Further, do not perform LID check for direct-routed packets, since > >> >permissive > >> >LID makes a proper check impossible. > >> > >> Thanks - I'll look at this within the next couple of days. > > > >Could this patch be merged please? Sean? > > There was a request to submit the LMC cache piece as a separate patch. I can > merge in the MAD changes after the LMC cache has been accepted. Roland, could this get merged please? -- 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 00/12] SRP: Changing ibsrpdm
On Mon, May 01, 2006 at 10:53:36AM -0700, Roland Dreier wrote: > Ishai> Hi, I'm going to send 12 patches. 6 patches for the kernel, > Ishai> and 6 for the userspace ibsrpdm. The kernel patches avoid > Ishai> adding the same target twice, allow the removal of a > Ishai> target, and add a query about the connected targets. > > In the future can you use a different descriptive title for each patch? OK > > Also (although I haven't reviewed the actual code yet) this mostly > makes sense, but I'm not sure we want to disallow connecting to the > same target twice. Userspace may want to implement a policy of one > conncetion per target, but having multiple connections to the same > target for multipathing/failover seems like something the kernel > should allow. What was your reason for forbidding this? > > - R. As I understand it, the path in multipathing is going to be part of the attributes of the connection to the target. So there will be no problem to add the same target twice, if it has a different path leading to it. -- Ishai Rabinovitz ___ 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 5 of 13] ipath - use proper address translation routine
Arjan> sounds like you need to redesign your layering ;) In linux Arjan> it's common to have the lowest level driver do the mapping Arjan> (even when the mid layer will provide the most commonly Arjan> used helper to do it for the common case)... It's not that simple of course... InfiniBand allows RDMA -- _remote_ DMA. So that address might be something that a protocol sent to the remote host and which is now showing up for a DMA operation initiated by the remote side. And we can't very well send a struct page * + offset to the remote side... ___ 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 06/12] SRP: Changing ibsrpdm
This patch is not acceptable. It's totally violating the sysfs "one-value-per-file" rule. What's wrong with the existing info in sysfs? - 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 5 of 13] ipath - use proper address translation routine
On Mon, 2006-05-01 at 12:00 -0700, Roland Dreier wrote: > Arjan> do you really NEED the vaddr? (most of the time linux > Arjan> drivers don't need it, while other OSes do) If you really > Arjan> need it you should grab it at dma_map time ... (and > Arjan> realize that it's not kernel addressable per se ;) > > Yes, they need some kind of vaddr. > > It's kind of a layering problem. The IB stack assumes that IB devices > have a DMA engine that deals with bus addresses. But the ipath driver > has to simulate this by using a memcpy on the CPU to move data to the > PCI device. > > I really don't know what the right solution is. Maybe having some way > to override the dma mapping operations so that the ipath driver can > keep the info it needs? sounds like you need to redesign your layering ;) In linux it's common to have the lowest level driver do the mapping (even when the mid layer will provide the most commonly used helper to do it for the common case)... ___ 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 13 of 13] ipath - tidy up white space in a few files
Applied all except 5/13 and 8/13... ___ 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 06/12] SRP: Changing ibsrpdm
On Mon, May 01, 2006 at 04:50:32PM +0300, Muli Ben-Yehuda wrote:
> On Mon, May 01, 2006 at 02:28:48PM +0300, Ishai Rabinovitz wrote:
> >
> > Support a display of list of target from user level.
> >
> > Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
> > Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
> > ===
> > --- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-04-21
> > 01:13:04.0 +0300
> > +++ last_stable/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-21
> > 03:56:05.0 +0300
> > @@ -1730,6 +1730,63 @@ end:
> >
> > static CLASS_DEVICE_ATTR(remove_target, S_IWUSR, NULL, srp_remove_target);
> >
> > +#define TARGET_INFO_BUF_SIZE 126
> > +
> > +static ssize_t list_targets(struct class_device *class_dev, char *buf)
> > +{
> > + struct srp_host *host =
> > + container_of(class_dev, struct srp_host, class_dev);
> > + struct srp_target_port *target;
> > + int printed=0, ret;
> > +
> > + mutex_lock(&host->target_mutex);
> > + list_for_each_entry(target, &host->target_list, list)
>
> Can this race with list addition / removal? I saw that you removed the
> lock in an earlier patch?
No, In an erlier patch I did not removed the lock, I enlarged it scope to
include
the entire call to srp_find_target.
>
> > + if (target->state == SRP_TARGET_LIVE) {
>
> You'd have an easier time with the indentation if you'd do
>
> if (target->state != SRP_TARGET_LIVE)
> continue;
>
> here
>
> > + ret = sprintf(buf+printed,
> > + "id_ext=%016llx,ioc_guid=%016llx,"
> > + "dgid=%04x%04x%04x%04x%04x%04x%04x%04x,"
> > + "pkey=%04x,service_id=%016llx\n",
> > + (unsigned long long)
> > + be64_to_cpu(target->id_ext),
> > + (unsigned long long)
> > + be64_to_cpu(target->ioc_guid),
> > + (int) be16_to_cpu(*(__be16 *)
> > + &target->path.dgid.raw[0]),
> > + (int) be16_to_cpu(*(__be16 *)
> > + &target->path.dgid.raw[2]),
> > + (int) be16_to_cpu(*(__be16 *)
> > + &target->path.dgid.raw[4]),
> > + (int) be16_to_cpu(*(__be16 *)
> > + &target->path.dgid.raw[6]),
> > + (int) be16_to_cpu(*(__be16 *)
> > + &target->path.dgid.raw[8]),
> > + (int) be16_to_cpu(*(__be16 *)
> > + &target->path.dgid.raw[10]),
> > + (int) be16_to_cpu(*(__be16 *)
> > + &target->path.dgid.raw[12]),
> > + (int) be16_to_cpu(*(__be16 *)
> > + &target->path.dgid.raw[14]),
>
> This is pretty horrible - could you use show_dgid() here?
Id will add a redundant copy of the buffer.
>
> Cheers,
> Muli
--
Ishai Rabinovitz
___
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] InfiniBand driver fixes for 2.6.17
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 This is mostly fixes for the ipath driver, with one mthca driver fix thrown in. The exact changes and patch are: Bryan O'Sullivan: IB/ipath: fix race with exposing reset file IB/ipath: set up 32-bit DMA mask if 64-bit setup fails IB/ipath: iterate over correct number of ports during reset IB/ipath: change handling of PIO buffers IB/ipath: fix verbs registration IB/ipath: prevent hardware from being accessed during reset IB/ipath: simplify RC send posting IB/ipath: simplify IB timer usage IB/ipath: improve sparse annotation IB/ipath: fix label name in interrupt handler IB/ipath: tidy up white space in a few files Roland Dreier: IB/mthca: Fix offset in query_gid method drivers/infiniband/hw/ipath/ipath_debug.h | 15 +- drivers/infiniband/hw/ipath/ipath_diag.c |3 +- drivers/infiniband/hw/ipath/ipath_driver.c| 18 +--- drivers/infiniband/hw/ipath/ipath_init_chip.c | 36 ++- drivers/infiniband/hw/ipath/ipath_intr.c | 21 +++-- drivers/infiniband/hw/ipath/ipath_kernel.h| 10 +++--- drivers/infiniband/hw/ipath/ipath_layer.c |6 +++- drivers/infiniband/hw/ipath/ipath_pe800.c |4 +++ drivers/infiniband/hw/ipath/ipath_registers.h | 31 drivers/infiniband/hw/ipath/ipath_ruc.c | 15 +++--- drivers/infiniband/hw/ipath/ipath_sysfs.c | 14 - drivers/infiniband/hw/ipath/ipath_ud.c|6 +++- drivers/infiniband/hw/ipath/ipath_verbs.c | 39 ++--- drivers/infiniband/hw/ipath/ipath_verbs.h |3 +- drivers/infiniband/hw/ipath/ips_common.h |2 + drivers/infiniband/hw/mthca/mthca_provider.c |2 + 16 files changed, 131 insertions(+), 94 deletions(-) diff --git a/drivers/infiniband/hw/ipath/ipath_debug.h b/drivers/infiniband/hw/ipath/ipath_debug.h index 593e289..4676238 100644 --- a/drivers/infiniband/hw/ipath/ipath_debug.h +++ b/drivers/infiniband/hw/ipath/ipath_debug.h @@ -60,11 +60,11 @@ #define __IPATH_KERNEL_SEND 0x2000 /* use kernel mode send */ #define __IPATH_EPKTDBG 0x4000 /* print ethernet packet data */ #define __IPATH_SMADBG 0x8000 /* sma packet debug */ -#define __IPATH_IPATHDBG0x1/* Ethernet (IPATH) general debug on */ -#define __IPATH_IPATHWARN 0x2/* Ethernet (IPATH) warnings on */ -#define __IPATH_IPATHERR0x4/* Ethernet (IPATH) errors on */ -#define __IPATH_IPATHPD 0x8/* Ethernet (IPATH) packet dump on */ -#define __IPATH_IPATHTABLE 0x10 /* Ethernet (IPATH) table dump on */ +#define __IPATH_IPATHDBG0x1/* Ethernet (IPATH) gen debug */ +#define __IPATH_IPATHWARN 0x2/* Ethernet (IPATH) warnings */ +#define __IPATH_IPATHERR0x4/* Ethernet (IPATH) errors */ +#define __IPATH_IPATHPD 0x8/* Ethernet (IPATH) packet dump */ +#define __IPATH_IPATHTABLE 0x10 /* Ethernet (IPATH) table dump */ #else /* _IPATH_DEBUGGING */ @@ -79,11 +79,12 @@ #define __IPATH_TRSAMPLE 0x0 /* generate trace buffer sample entries */ #define __IPATH_VERBDBG 0x0 /* very verbose debug */ #define __IPATH_PKTDBG0x0 /* print packet data */ -#define __IPATH_PROCDBG 0x0 /* print process startup (init)/exit messages */ +#define __IPATH_PROCDBG 0x0 /* process startup (init)/exit messages */ /* print mmap/nopage stuff, not using VDBG any more */ #define __IPATH_MMDBG 0x0 #define __IPATH_EPKTDBG 0x0 /* print ethernet packet data */ -#define __IPATH_SMADBG0x0 /* print process startup (init)/exit messages */#define __IPATH_IPATHDBG 0x0 /* Ethernet (IPATH) table dump on */ +#define __IPATH_SMADBG0x0 /* process startup (init)/exit messages */ +#define __IPATH_IPATHDBG 0x0 /* Ethernet (IPATH) table dump on */ #define __IPATH_IPATHWARN 0x0 /* Ethernet (IPATH) warnings on */ #define __IPATH_IPATHERR 0x0 /* Ethernet (IPATH) errors on */ #define __IPATH_IPATHPD 0x0 /* Ethernet (IPATH) packet dump on */ diff --git a/drivers/infiniband/hw/ipath/ipath_diag.c b/drivers/infiniband/hw/ipath/ipath_diag.c index 7d3fb69..28ddceb 100644 --- a/drivers/infiniband/hw/ipath/ipath_diag.c +++ b/drivers/infiniband/hw/ipath/ipath_diag.c @@ -277,13 +277,14 @@ static int ipath_diag_open(struct inode bail: spin_unlock_irqrestore(&ipath_devs_lock, flags); - mutex_unlock(&ipath_mutex); /* Only expose a way to reset the device if we make it into diag mode. */ if (ret == 0) ipath_expose_reset(&dd->pcidev->dev); + mutex_unlock(&ipath_mutex); + return ret; } diff --git a/drivers/i
Re: [openib-general] [PATCH 04/12] SRP: Changing ibsrpdm
Ishai> Do you think we should always use irqsave just to be on the Ishai> safe side (Maybe in the future someone else will call us)? Not in a function that does mutex_lock() also... - 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 04/12] SRP: Changing ibsrpdm
On Mon, May 01, 2006 at 04:43:23PM +0300, Muli Ben-Yehuda wrote:
> On Mon, May 01, 2006 at 02:27:39PM +0300, Ishai Rabinovitz wrote:
> >
> > Do not add the same target twice.
> >
> > Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
> > Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
> > ===
> > --- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-04-25
> > 15:17:34.0 +0300
> > +++ last_stable/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-25
> > 15:19:37.0 +0300
> > @@ -1478,7 +1478,8 @@ static int srp_parse_options(const char
> > printk(KERN_WARNING PFX "bad max sect parameter
> > '%s'\n", p);
> > goto out;
> > }
> > - target->scsi_host->max_sectors = token;
> > + if (target->scsi_host != NULL)
> > + target->scsi_host->max_sectors = token;
> > break;
>
> This chunk does not look related to the rest. Is a NULL
> target->scsi_host legal here? if not, the check should be removed as
> we'd rather take an oops here than hide the problem behind the NULL
> pointer check.
>
> > +/* srp_find_target - If the target exists return it in target,
> > + otherwise target is set to NULL.
> > + host->target_mutex should be hold */
>
> Please use the usual kernel
> /*
> * stuff
> */
> style for multi line comments.
OK, Thanks.
>
> > +static int srp_find_target(const char *buf, struct srp_host *host,
> > + struct srp_target_port **target)
> > +{
> > + struct srp_target_port *target_to_find, *curr_target;
> > + int ret, i;
> > +
> > + target_to_find = kzalloc(sizeof *target_to_find, GFP_KERNEL);
> > + ret = srp_parse_options(buf, target_to_find);
> > + if (ret)
> > + goto free;
> > +
> > + list_for_each_entry(curr_target, &host->target_list, list)
> > + if (target_to_find->ioc_guid == curr_target->ioc_guid &&
> > + target_to_find->id_ext == curr_target->id_ext &&
> > + target_to_find->path.pkey == curr_target->path.pkey &&
> > + target_to_find->service_id == curr_target->service_id) {
> > + for (i = 0; i < 16; ++i)
> > + if (target_to_find->path.dgid.raw[i] !=
> > curr_target->path.dgid.raw[i])
> > + break;
>
> The conditional and check here probably deserves an inline helper
> called same_target() or some such.
>
> > + if (i == 16) {
> > + *target = curr_target;
> > + goto free;
> > + }
> > + }
> > +
> > + *target = NULL;
> > +
> > +free:
> > + kfree(target_to_find);
> > + return 0;
>
> We always return 0 - either this should return void, or you meant to
> return ret here instead of 0?
You are right as usual, We should return ret.
>
> > +}
> > +
> > static ssize_t srp_create_target(struct class_device *class_dev,
> > const char *buf, size_t count)
> > {
> > struct srp_host *host =
> > container_of(class_dev, struct srp_host, class_dev);
> > struct Scsi_Host *target_host;
> > - struct srp_target_port *target;
> > + struct srp_target_port *target, *existing_target = NULL;
> > int ret;
> > int i;
> >
> > + /* first check if the target already exists */
> > +
> > + mutex_lock(&host->target_mutex);
> > + ret = srp_find_target(buf, host, &existing_target);
> > + if (ret)
> > + goto unlock_mutex;
> > +
> > + if (existing_target) {
> > + /* target already exists */
> > + spin_lock_irq(existing_target->scsi_host->host_lock);
>
> why _irq and not _irqsave? Are you sure this code can't ever be called
> with interrupts off via some other path?
This function is being called from userspace
(writing to /sys/class/infiniband_srp/.../add_target) so no need for irqsave.
Do you think we should always use irqsave just to be on the safe side (Maybe
in the future someone else will call us)?
>
> Cheers,
> Muli
--- Resending the fixed patch --
-
Do not add the same target twice.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-04-25
15:17:34.0 +0300
+++ last_stable/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-25
15:19:37.0 +0300
@@ -1478,7 +1478,8 @@ static int srp_parse_options(const char
printk(KERN_WARNING PFX "bad max sect parameter
'%s'\n", p);
goto out;
}
-
[openib-general] Re: [PATCH 5 of 13] ipath - use proper address translation routine
On Mon, 2006-05-01 at 11:50 -0700, Roland Dreier wrote: > Bryan> Move away from an obsolete, unportable routine for > Bryan> translating physical addresses. > > This change: > > > - isge->vaddr = bus_to_virt(sge->addr); > > + isge->vaddr = phys_to_virt(sge->addr); > > is really wrong. bus_to_virt() is really what you want, because in > this case the address is a bus address that came from dma_map_xxx(). Well, bus_to_virt is not portable, so we definitely can't use it. I'll have to do some thinking about this. http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 5 of 13] ipath - use proper address translation routine
Arjan> do you really NEED the vaddr? (most of the time linux Arjan> drivers don't need it, while other OSes do) If you really Arjan> need it you should grab it at dma_map time ... (and Arjan> realize that it's not kernel addressable per se ;) Yes, they need some kind of vaddr. It's kind of a layering problem. The IB stack assumes that IB devices have a DMA engine that deals with bus addresses. But the ipath driver has to simulate this by using a memcpy on the CPU to move data to the PCI device. I really don't know what the right solution is. Maybe having some way to override the dma mapping operations so that the ipath driver can keep the info it needs? - 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] [PATCHE 02/12] SRP: changing ibsrpdm
On Mon, May 01, 2006 at 04:33:42PM +0300, Muli Ben-Yehuda wrote:
> On Mon, May 01, 2006 at 02:25:46PM +0300, Ishai Rabinovitz wrote:
> >
> > Move the destruction of the host and the removal from a list to a function.
> >
> > Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
> >
> > Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
> > ===
> > --- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-04-23
> > 14:08:03.0 +0300
> > +++ last_stable/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-24
> > 10:47:00.0 +0300
> > @@ -344,6 +344,16 @@ static void srp_disconnect_target(struct
> > wait_for_completion(&target->done);
> > }
> >
> > +static void destruct_scsi_host_and_target(struct srp_target_port *target,
> > int disconnect_target)
> > +{
> > + scsi_remove_host(target->scsi_host);
> > + if (disconnect_target)
> > + srp_disconnect_target(target);
> > + ib_destroy_cm_id(target->cm_id);
> > + srp_free_target_ib(target);
> > + scsi_host_put(target->scsi_host);
> > +}
> > +
> > static void srp_remove_work(void *target_ptr)
> > {
> > struct srp_target_port *target = target_ptr;
> > @@ -357,10 +374,7 @@ static void srp_remove_work(void *target
> > list_del(&target->list);
> > mutex_unlock(&target->srp_host->target_mutex);
> >
> > - scsi_remove_host(target->scsi_host);
> > - ib_destroy_cm_id(target->cm_id);
> > - srp_free_target_ib(target);
> > - scsi_host_put(target->scsi_host);
> > + destruct_scsi_host_and_target(target, 0);
>
> Is not disconnecting from the target here actually the right thing to
> do? considering we're then destroying the target's queue pairs and
> freeing it?
>
> Cheers,
> Muli
Hi Muli,
srp_remove_target is being called only when we were unable to reconnect
in srp_reconnect_target so the target is already disconnected.
Ishai
--
Ishai Rabinovitz
___
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 5 of 13] ipath - use proper address translation routine
On Mon, 2006-05-01 at 11:50 -0700, Roland Dreier wrote: > Bryan> Move away from an obsolete, unportable routine for > Bryan> translating physical addresses. > > This change: > > > - isge->vaddr = bus_to_virt(sge->addr); > > + isge->vaddr = phys_to_virt(sge->addr); > > is really wrong. bus_to_virt() is really what you want, because in > this case the address is a bus address that came from dma_map_xxx(). > You're still going to be hosed on systems with IOMMUs for example. do you really NEED the vaddr? (most of the time linux drivers don't need it, while other OSes do) If you really need it you should grab it at dma_map time ... (and realize that it's not kernel addressable per se ;) ___ 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 5 of 13] ipath - use proper address translation routine
Bryan> Move away from an obsolete, unportable routine for Bryan> translating physical addresses. This change: > -isge->vaddr = bus_to_virt(sge->addr); > +isge->vaddr = phys_to_virt(sge->addr); is really wrong. bus_to_virt() is really what you want, because in this case the address is a bus address that came from dma_map_xxx(). You're still going to be hosed on systems with IOMMUs for example. - 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 2 of 13] ipath - set up 32-bit DMA mask if 64-bit setup fails
Bryan> Some systems do not set up 64-bit maps on systems with 2GB
Bryan> or less of memory installed, so we have to fall back to
Bryan> trying a 32-bit setup.
Which systems does this happen on? I'm just curious, because mthca has
err = pci_set_dma_mask(pdev, DMA_64BIT_MASK);
if (err) {
dev_warn(&pdev->dev, "Warning: couldn't set 64-bit PCI DMA
mask.\n");
and I've never had a single report of that warning triggering.
- 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 0/6] iSER (iSCSI Extensions for RDMA) initiator
Is this ready for queuing in my for-2.6.18 tree? What is the status of all the non-IB dependencies? If it is ready for merging, please send me a clean patch series with the comments from this thread addressed. And also remind me of which SCSI git trees this depends on... 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
[openib-general] Re: [PATCH] SRP: Avoid a potential deadlock
Ishai> Avoid a potential dead-lock. In srp_disconnect_target Ishai> there is a call to ib_send_cm_dreq and a wait for Ishai> completion If when getting DREP there is no comp no one Ishai> will end this wait I thought that after the DREP is received, the CM will go through timewait and we will eventually get a TIMEWAIT_EXIT event (with a completion). Am I wrong? Have you actually seen this deadlock happen in practice? - 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] RFC: detecting duplicate MAD requests
>It needs to fail in a way so that it is not retried, right ? The ib_post_send_mad() call will fail. Since the first response removed the request from the list to check, subsequent retries will also fail. Basically, this prevents a user from sending a response MAD unless it had previously received a request. - 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] RFC: detecting duplicate MAD requests
>Why is the requester resending ? He's simply timed out waiting for a response. For instance, if this is an SA query, maybe the SA is swamped with requests. I don't think that there are any timeout restrictions for this. - 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] RFC: detecting duplicate MAD requests
On Mon, 2006-05-01 at 14:13, Sean Hefty wrote: > >There's still a window here depending on when free MAD is called versus > >when the response gets back to the original requester. > > There are no issues in this case. We just need to avoid having two responses > being sent at the same time. > > >> but I'm not sure if this would happen in practice. A > >> second drawback is that the receive MAD would need to be kept around until > >the > >> send completed (as opposed to the send started). > > > >Is this to handle the case where free MAD is called prior to the send > >completing ? Is this on the response side only ? > > The basic idea is that when a MAD with the response bit set is sent, a check > is > made against a list received MADs that have been reported to the user. If a > received MAD is found, it is removed from the list, and the response is sent. > If no request is found (e.g. the MAD had already been freed), then the send > fails. It needs to fail in a way so that it is not retried, right ? -- 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
RE: [openib-general] RFC: detecting duplicate MAD requests
>Aren't there 3 cases possible here: (1) non RMPP request/RMPP response >(e.g. SA GetTable for one), (2) RMPP request/RMPP response (e.g. SA >GetMulti), and (3) RMPP request/non RMPP response (I don't think this >currently exists but may be mistaken). Are all handled on the >initiator/requester side ? Are the changes only for case (2) ? For case 1, we don't have DS RMPP. For case 2, we have DS RMPP. And I don't believe that case 3 exists either, but would end up being treated as DS RMPP by the implementation. If case 3 doesn't exist, then I think we can come up with a generic way to identify DS RMPP that doesn't require checking class or methods. If case 3 does exist, then I think we'll need class / method checking to identify DS RMPP. - 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] RFC: detecting duplicate MAD requests
On Mon, 2006-05-01 at 14:04, Sean Hefty wrote: > >> There is a real issue that is seen when a duplicate request (same TID, > >> SGID, > >> mgmt class) is received at the client, resulting in a duplicate response. > > > >You had mentioned in the previous email on this that this was the case > >of a slow responder. Is the responder slow but playing by the IB > >timeouts in effect or is it violating those timeouts ? > > I don't believe that the responder is violating any timeouts. Why is the requester resending ? > >> The MAD layer cannot allow the duplicate response to be sent because of > >> RMPP > >issues. > > > >Is this different for non RMPP MADs v. RMPP MADs ? Is the RMPP issue > >what you mention below (RMPP receiving a duplicate response) ? If so, is > >this an implementation or architecture issue or both ? > > The issue is a result of the RMPP architecture, but I wouldn't say that RMPP > has > an issue. It's simply a matter that you can't reassemble multiple MADs from > the > same source that use the same transaction ID. > > For non-RMPP MADs, the only issue is one of efficiency. A duplicate response > would just be dropped on the requester side if the first response is received. > > >> A client is still restricted from sending a duplicate response while a > >previous > >> response is in progress. RMPP cannot handle this case. > > > >Why not ? Wouldn't the second response not match anything in the client > >on the request side ? > > This is true if the first response completes before the second response is > sent. > The problem is when both responses are active at the same time. > > - 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] RFC: detecting duplicate MAD requests
>There's still a window here depending on when free MAD is called versus >when the response gets back to the original requester. There are no issues in this case. We just need to avoid having two responses being sent at the same time. >> but I'm not sure if this would happen in practice. A >> second drawback is that the receive MAD would need to be kept around until >the >> send completed (as opposed to the send started). > >Is this to handle the case where free MAD is called prior to the send >completing ? Is this on the response side only ? The basic idea is that when a MAD with the response bit set is sent, a check is made against a list received MADs that have been reported to the user. If a received MAD is found, it is removed from the list, and the response is sent. If no request is found (e.g. the MAD had already been freed), then the send fails. - 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: SDP fails to compile on SVN6829
Michael wrote,
> do I need an additional patch or is the backport patch broken ?
Personally, I don't think we should be moving code into the trunk
until it is ready, and obviously this new SDP is not ready.
Anyone else have an opinion on how/when things get moved to the trunk ?
Shouldn't it be kept on a branch till it is ready ?
>I think you need these:
> A /gen2/branches/backport/2.6.9/linux_skbuff_6754_to_2_6_11.patch (from
>/gen2/branches/backport/2.6.11/linux_skbuff_6754_to_2_6_11.patch:6765)
For example, this patch adds a function
static inline void skb_header_release(struct sk_buff *skb)
that does not do anything yet.
Maybe I better wait till you have this new
SDP completed before moving to it, until then I will use the older
SDP.
woody
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ last_stable/include/linux/skbuff.h 2006-04-30 09:16:05.0 +0300
@@ -0,0 +1,19 @@
+#ifndef LINUX_SKBUFF_H_BACKPORT
+#define LINUX_SKBUFF_H_BACKPORT
+
+#include_next
+
+/**
+ * skb_header_release - release reference to header
+ * @skb: buffer to operate on
+ *
+ * Drop a reference to the header part of the buffer. This is done
+ * by acquiring a payload reference. You must not read from the
header
+ * part of skb->data after this.
+ */
+static inline void skb_header_release(struct sk_buff *skb)
+{
+}
+
+
+#endif
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] RFC: detecting duplicate MAD requests
>> There is a real issue that is seen when a duplicate request (same TID, SGID, >> mgmt class) is received at the client, resulting in a duplicate response. > >You had mentioned in the previous email on this that this was the case >of a slow responder. Is the responder slow but playing by the IB >timeouts in effect or is it violating those timeouts ? I don't believe that the responder is violating any timeouts. >> The MAD layer cannot allow the duplicate response to be sent because of RMPP >issues. > >Is this different for non RMPP MADs v. RMPP MADs ? Is the RMPP issue >what you mention below (RMPP receiving a duplicate response) ? If so, is >this an implementation or architecture issue or both ? The issue is a result of the RMPP architecture, but I wouldn't say that RMPP has an issue. It's simply a matter that you can't reassemble multiple MADs from the same source that use the same transaction ID. For non-RMPP MADs, the only issue is one of efficiency. A duplicate response would just be dropped on the requester side if the first response is received. >> A client is still restricted from sending a duplicate response while a >previous >> response is in progress. RMPP cannot handle this case. > >Why not ? Wouldn't the second response not match anything in the client >on the request side ? This is true if the first response completes before the second response is sent. The problem is when both responses are active at the same time. - 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] Problem running mpdboot command in MVAPICH2 v0.9.3-RC0
Hi Wei, Thanks for a prompt reply. Yes, I did originally export the LD_LIBRARY_PATH in .bashrc as followed: export LD_LIBRARY_PATH=/usr/local/lib I've also tried your suggestion: export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH In either case, issue still exists. Given the same setup, I did NOT see this issue in v0.9.2 (obtained from https://openib.org/svn/gen2/trunk/src/userspace/mpi/mvapich2-gen2). Thanks, Albert Original Message- From: wei huang [mailto:[EMAIL PROTECTED] Sent: Saturday, April 29, 2006 2:09 PM To: Albert To Cc: openib-general@openib.org Subject: Re: [openib-general] Problem running mpdboot command in MVAPICH2 v0.9.3-RC0 Hi Albert, Not sure if you export /usr/local/lib to LD_LIBRARY_PATH manually or it is in your bashrc. Could you please try to put export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH in your .bashrc (assume using bash) and try again? Thanks. Regards, Wei Huang 774 Dreese Lab, 2015 Neil Ave, Dept. of Computer Science and Engineering Ohio State University OH 43210 Tel: (614)292-8501 On Fri, 28 Apr 2006, Albert To wrote: > Hi, > > I downloaded and compiled the MVAPICH2 v0.9.3-RC0 using > make.mvapich2.gen2 script. The script finished without any errors. > However, I received "mpdboot: error while loading shared libraries: > libibverbs.so.1: cannot open shared object file: No such file or > directory" error while executing mpdboot -n 2 -f mpd.hosts. I checked > library file libibverbs.so.1 and found it in /usr/local/lib folder. > LD_LIBRARY_PATH is already set to /usr/local/bin, but that didn't help. > > Is there another environment variable that I need to set to make > mpdboot works? Thanks in advance for your help. > > -Albert > ___ 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 RDS missing features
Given this is an extension to Sockets, should it not also be reviewed by the Sockets owners? What about the API itself? Any plans to make this portable to other OS / endnodes or have a spec and associated wire protocol that is reviewed perhaps in the IETF so it is applicable to more than just Oracle? It seems this really should be standardized within the IETF to gain broad adoption and insure it will be interoperable across all implementations not just OpenFabric's. At 10:42 AM 5/1/2006, Ranjit Pandit wrote: On 5/1/06, Or Gerlitz <[EMAIL PROTECTED]> wrote: Can you elaborate on each of the features, specifically the following points are of interest to us: +1 so you running Oracle Loopback traffic over RDS sockets? if yes, what the issue here? the openib CMA supports listen/connect on loopback addresses (eg 127.0.0.1 or IPoIB local address) Yes. There is no issue. It's just next in line for me to implement. +2 by failover, are you referring to APM? that is failover between IB pathes to/from the same HCA over which the original connection/QP was established or you are talking on failover between HCAs Failover within and across HCAs. APM does not work for failover across HCAs. For OpenFabric, one would need to have this work across RNIC as well. APM is not part of iWARP so can't be relied upon. +3 is the no support for /proc like for RDS an issue to run crload or demo Oracle (that is specific tuning and usage of non defaults is needed for any/optimal operation) No, this does not affect core functionality. You should be able to run Oracle or crload without this feature. That was a list of things that still need to be implemented for GA and not just demo Or. [openfabrics-ewg] Before we can start testing - we needto ensure that RDS is fully ported. Pandit, Ranjit rpandit at silverstorm.com Following features are yet to be implemented in OpenFabric Rds: 1. Failover 2. Loopback connections 3. support for /proc fs like Rds config, stats and info. Ranjit ___ 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
[openib-general] Re: [PATCH 00/12] SRP: Changing ibsrpdm
Ishai> Hi, I'm going to send 12 patches. 6 patches for the kernel, Ishai> and 6 for the userspace ibsrpdm. The kernel patches avoid Ishai> adding the same target twice, allow the removal of a Ishai> target, and add a query about the connected targets. In the future can you use a different descriptive title for each patch? Also (although I haven't reviewed the actual code yet) this mostly makes sense, but I'm not sure we want to disallow connecting to the same target twice. Userspace may want to implement a policy of one conncetion per target, but having multiple connections to the same target for multipathing/failover seems like something the kernel should allow. What was your reason for forbidding this? - 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] re cma upcalls serialization / disconnected eventquestion
>Can a ULP assume that cma callbacks for to the same CMA ID
>are serialized?
Yes. (This is required to avoid reporting events out of order to the user.)
>Also and related to this, is it correct that ***always** before
>DISCONNECTED event there will be one of {ESTABLISHED, REJECTED,
>CONNECT_ERROR}?
You should always see ESTABLISHED before DISCONNECTED. If not, then there's a
bug in the CMA.
- 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 RDS missing features
> > +3 is the no support for /proc like for RDS an issue to run crload or > > demo Oracle (that is specific tuning > > and usage of non defaults is needed for any/optimal operation) > No, this does not affect core functionality. You should be able to run > Oracle or crload without this feature. Don't put RDS tunables in /proc. They don't have anything to do with processes. Probably the best place for them is in sysfs, following the "one value per file" rule. If you can't follow that rule then create your own filesystem. - 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] re RDS missing features
On 5/1/06, Or Gerlitz <[EMAIL PROTECTED]> wrote: Can you elaborate on each of the features, specifically the following points are of interest to us: +1 so you running Oracle Loopback traffic over RDS sockets? if yes, what the issue here? the openib CMA supports listen/connect on loopback addresses (eg 127.0.0.1 or IPoIB local address) Yes. There is no issue. It's just next in line for me to implement. +2 by failover, are you referring to APM? that is failover between IB pathes to/from the same HCA over which the original connection/QP was established or you are talking on failover between HCAs Failover within and across HCAs. APM does not work for failover across HCAs. +3 is the no support for /proc like for RDS an issue to run crload or demo Oracle (that is specific tuning and usage of non defaults is needed for any/optimal operation) No, this does not affect core functionality. You should be able to run Oracle or crload without this feature. That was a list of things that still need to be implemented for GA and not just demo Or. [openfabrics-ewg] Before we can start testing - we needto ensure that RDS is fully ported. Pandit, Ranjit rpandit at silverstorm.com Following features are yet to be implemented in OpenFabric Rds: 1. Failover 2. Loopback connections 3. support for /proc fs like Rds config, stats and info. Ranjit ___ 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 8 of 13] ipath - fix a number of RC protocol bugs
On Mon, 2006-05-01 at 10:22 -0700, Roland Dreier wrote: > Andrew> Please don't play around with list_head internals like > Andrew> this - some speedfreak might legitimately choose to remove > Andrew> the list_head poisoning debug code, or make it > Andrew> Kconfigurable. > > Bryan, can you fix this up and resend this patch? Yep. We already have a fix; I just need to put it in my queue. > Are the other patches independent of this? Should I apply all the > others, or do I need to wait for the fixed version of this one? They're all independent of this, so please fire away. Thanks, http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [RFC] AT and user AT
On Wed, 2006-04-26 at 10:00, Hal Rosenstock wrote: > As AT and user AT have been obsoleted (and superceeded by CMA which is > now in the process of going upstream), any objections to removing AT and > user AT from the trunk ? If I don't hear back by COB Friday, I will > presume this is OK. This is now done. AT and user AT are gone from the 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] Re: SDP fails to compile on SVN6829
Quoting r. Woodruff, Robert J <[EMAIL PROTECTED]>: > Subject: RE: SDP fails to compile on SVN6829 > > Michael wrote, > > >Which kernel are you building on? > > 2.6.9-34EL. > > >Looks like you might want the backport patches from > https://openib.org/svn/gen2/branches/backport > > I applied the sdp patch from 2.6.9_U3/sdp_6754_to_2_6_11.patch > but still get the error, > > > drivers/infiniband/ulp/sdp/sdp.h:6:27: net/inet_sock.h: No such file > or > > directory > > do I need an additional patch or is the backport patch broken ? I think you need these: A /gen2/branches/backport/2.6.9/linux_skbuff_6754_to_2_6_11.patch (from /gen2/branches/backport/2.6.11/linux_skbuff_6754_to_2_6_11.patch:6765) A /gen2/branches/backport/2.6.9/net_inet_sock_6754_to_2_6_15.patch (from /gen2/branches/backport/2.6.11/net_inet_sock_6754_to_2_6_15.patch:6765) A /gen2/branches/backport/2.6.9/net_sock_1_6754_to_2_6_13.patch (from /gen2/branches/backport/2.6.11/net_sock_1_6754_to_2_6_13.patch:6765) A /gen2/branches/backport/2.6.9/net_sock_2_6754_to_2_6_11.patch (from /gen2/branches/backport/2.6.11/net_sock_2_6754_to_2_6_11.patch:6767) A /gen2/branches/backport/2.6.9/net_tcp_states_6754_to_2_6_13.patch (from /gen2/branches/backport/2.6.11/net_tcp_states_6754_to_2_6_13.patch:6765) A /gen2/branches/backport/2.6.9/sdp_6754_to_2_6_11.patch (from /gen2/branches/backport/2.6.11/sdp_6754_to_2_6_11.patch:6765) A /gen2/branches/backport/2.6.9_U3/linux_skbuff_6754_to_2_6_11.patch (from /gen2/branches/backport/2.6.11/linux_skbuff_6754_to_2_6_11.patch:6765) A /gen2/branches/backport/2.6.9_U3/net_inet_sock_6754_to_2_6_15.patch (from /gen2/branches/backport/2.6.11/net_inet_sock_6754_to_2_6_15.patch:6765) A /gen2/branches/backport/2.6.9_U3/net_sock_1_6754_to_2_6_13.patch (from /gen2/branches/backport/2.6.11/net_sock_1_6754_to_2_6_13.patch:6765) A /gen2/branches/backport/2.6.9_U3/net_sock_2_6754_to_2_6_11.patch (from /gen2/branches/backport/2.6.11/net_sock_2_6754_to_2_6_11.patch:6767) A /gen2/branches/backport/2.6.9_U3/net_tcp_states_6754_to_2_6_13.patch (from /gen2/branches/backport/2.6.11/net_tcp_states_6754_to_2_6_13.patch:6765) A /gen2/branches/backport/2.6.9_U3/sdp_6754_to_2_6_11.patch (from /gen2/branches/backport/2.6.11/sdp_6754_to_2_6_11.patch:6765) -- 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 8 of 13] ipath - fix a number of RC protocol bugs
Andrew> Please don't play around with list_head internals like Andrew> this - some speedfreak might legitimately choose to remove Andrew> the list_head poisoning debug code, or make it Andrew> Kconfigurable. Bryan, can you fix this up and resend this patch? Are the other patches independent of this? Should I apply all the others, or do I need to wait for the fixed version of this one? - 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] [RFC] AT and user AT
On Wed, 2006-04-26 at 12:15, Hal Rosenstock wrote: > On Wed, 2006-04-26 at 11:00, James Lentini wrote: > > On Wed, 26 Apr 2006, Hal Rosenstock wrote: > > > > > As AT and user AT have been obsoleted (and superceeded by CMA which > > > is now in the process of going upstream), any objections to removnow ing > > > AT and user AT from the trunk ? If I don't hear back by COB Friday, > > > I will presume this is OK. > > > > I'm in agreement with moving this off of the trunk. > > > > Will the code still be available for reference? > > Sure. I can move it somewhere before deleting it from the trunk. Both AT and user AT are now saved as https://openib.org/svn/gen2/branches/ibat -- Hal > -- 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] sdp code in trunk
Micheal wrote, >Hello! >I have replaced the SDP code on trunk with new, much smaller code base, >based on CMA. Note that only bcopy mode is supported. >The old sdp code has been moved to https://openib.org/svn/gen2/branches/sdp_historic >Please note that smaller LOC count does not mean less bugs yet - in fact, while >the CMA code (mostly sdp_cma.c) is ready and works well for me, the data >transfer part is in active development, and I'm aware of several race >condition/data corruption issues which prevent it from being generally useful >just yet, and which I am in the process of addressing. >-- >MST Should we be replacing stable code in the trunk with code that is known to be unstable ? Seems like we should wait till it is useful before moving it into the trunk. Anyone else have an opinion on this one ? woody ___ 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 fails to compile on SVN6829
Michael wrote, >Which kernel are you building on? 2.6.9-34EL. >Looks like you might want the backport patches from https://openib.org/svn/gen2/branches/backport I applied the sdp patch from 2.6.9_U3/sdp_6754_to_2_6_11.patch but still get the error, > drivers/infiniband/ulp/sdp/sdp.h:6:27: net/inet_sock.h: No such file or > directory do I need an additional patch or is the backport patch broken ? woody ___ 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 fails to compile on SVN6829
Quoting r. Bob Woodruff <[EMAIL PROTECTED]>: > Subject: SDP fails to compile on SVN6829 > > > When I try to build SDP from SVN6829, I get the following error. > In file included from drivers/infiniband/ulp/sdp/sdp_main.c:44: > drivers/infiniband/ulp/sdp/sdp.h:6:27: net/inet_sock.h: No such file or > directory > > Looks like there is a new include/net directory but no header file > inet_sock.h in it. > > woody > Which kernel are you building on? Looks like you might want the backport patches from https://openib.org/svn/gen2/branches/backport -- 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] Do we want the change of not using libsysfs in OFED?
Tziporet> Hi, After RC3 time frame Roland changed the trunk to Tziporet> avoid usage of libsysfs. Currently this change was not Tziporet> applied to the branch thus it is not in OFED RC4. Tziporet> Do we want this change to be in OFED too? Actually the trunk still uses libsysfs, it just uses it less. There should be no functional change, but of course there's always the chance of regression. So there's no strong reason to merge the changes from the trunk. - 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] ib_srp
Di> Hi, Is there a way to remove a target from the SRP Di> configuration without unloading the driver module (which seems Di> to have partially removed the disk, but appears to be Di> hanging)? Unloading the module should work. A trace from sysrq-t that shows where rmmod/modprobe -r is hanging would be useful. Right now there isn't a way to disconnect from a particular target port without unloading the module though. - 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] Re: [PATCH 00/16] ehca: IBM eHCA InfiniBand Device Driver
Heiko> I don't like the idea to put the whole driver in one patch Heiko> file. I would propose to put the patch "ehca: integration Heiko> in Linux kernel" last instead of first, as Arnd Heiko> mentioned. With that change we leave the kernel in a Heiko> working state when applying the patches. Yes, that makes sense. And I can fold the patches into a single git changeset when we finally merge it, since I don't see any advantage to having the driver split into pieces. (No one is going to git biset a half-applied driver or anything like that) - 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] SRP: fix crash in srp_process_rsp
Ishai> srp_process_rsp crashes on NULL pointer dereference. Ishai> The following fixes the crash. Is this a correct fix? We should never get a RSP for a request without a a command associated. So this is just covering up a driver bug. How do you hit this crash? - 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] [RFC] [PATCH 1/3] RDMA CM: add rdma_get/set_optioncalls to get/set path records
> > I don't think that we want to start adding a new set of APIs for every > > option that may eventually need to be supported. > Why not? Agreed... as an interface to userspace, get/set opt makes sense, but inside the kernel you just end up with a dispatch function that demultiplexes things to the real work. So I think the real work functions should be the kernel API. - 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] SDP fails to compile on SVN6829
When I try to build SDP from SVN6829, I get the following error. In file included from drivers/infiniband/ulp/sdp/sdp_main.c:44: drivers/infiniband/ulp/sdp/sdp.h:6:27: net/inet_sock.h: No such file or directory Looks like there is a new include/net directory but no header file inet_sock.h in it. woody ___ 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 2/2] Wean libehca off of libsysfs
Heiko> Hello Roland, does OpenIB 1.0 RC2 (RC3, ...) still uses Heiko> libsysfs or is it only change for subversion head (trunk)? All versions of libibverbs still use libsysfs. However this patch for libehca reduces the dependency on libsysfs and will make the transition to a no-libsysfs world smoother. - 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][UVERBS][RFC] Exporting device node_type to user mode
Tom> Roland: Thinking about this a little more and having read Tom> some less than flattering commentary on various mailing list Tom> about sysfs, ABI, differences between distros, etc... Is Tom> using sysfs for device attributes the right approach here, or Tom> should be bite the bullet and update the kernel-abi? Well, we already have node_type in sysfs. I don't think it's worth adding a redundant way to get the info, and we're already using sysfs for stuff like node_guid anyway. - 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] sdp code in trunk
Hello! I have replaced the SDP code on trunk with new, much smaller code base, based on CMA. Note that only bcopy mode is supported. The old sdp code has been moved to https://openib.org/svn/gen2/branches/sdp_historic Please note that smaller LOC count does not mean less bugs yet - in fact, while the CMA code (mostly sdp_cma.c) is ready and works well for me, the data transfer part is in active development, and I'm aware of several race condition/data corruption issues which prevent it from being generally useful just yet, and which I am in the process of addressing. -- 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] Do we want the change of not using libsysfs in OFED?
Hi, After RC3 time frame Roland changed the trunk to avoid usage of libsysfs. Currently this change was not applied to the branch thus it is not in OFED RC4. Do we want this change to be in OFED too? Note that in any case it will not be in RC4 but it can be done for RC5 with SDP. Tziporet ___ 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: [openfabrics-ewg] OFED release plan - update on RC4 status
Title: OFED release plan Tziporet Koren wrote: Hi All, This is the release plan: 1. RC3 – target: All components are in Schedule: done on Apr-10. 2. RC4 – target: features freeze – meaning all features and modules targeted for 1.0 release should be in. Schedule: May-4 (delayed from May-1 since some modules are not ready yet) Main changes from RC3 to RC4: 1. Bug fixes according to problems reported. 2. SDP - new code that Michael Tsirkin developed. 3. SRP - with new features: FMR, tunable parameters, SRP daemon 4. Open MPI – new package based on 1.1a3 5. RDS – new version from main trunk 6. Kernel code based on git 7. Standard network configuration Its seems that SDP will not make it this week thus RC4 will not include the new SDP code. Note that the new code is already checked-in to the main trunk so anyone who wish looking at it can start the review. Since there are many other changes in this RC that need testing we will not delay RC4. We may add another RC at end of next week adding SDP only. Tziporet ___ 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: detecting duplicate MAD requests
On Sat, 2006-04-29 at 02:23, Sean Hefty wrote: > >You can't add this kind of thing piecemeal to a protocol and have it > >work. If the sender doesn't see a response (perhaps the response was > >lost, or was slow coming), and sends another MAD, this 2nd MAD will > >have a different sequence number. How does the recipient know it's the > > If a MAD is sent with a different sequence number (transaction ID), then it's > a > different transaction or request. > > There is a real issue that is seen when a duplicate request (same TID, SGID, > mgmt class) is received at the client, resulting in a duplicate response. You had mentioned in the previous email on this that this was the case of a slow responder. Is the responder slow but playing by the IB timeouts in effect or is it violating those timeouts ? > The MAD layer cannot allow the duplicate response to be sent because of RMPP > issues. Is this different for non RMPP MADs v. RMPP MADs ? Is the RMPP issue what you mention below (RMPP receiving a duplicate response) ? If so, is this an implementation or architecture issue or both ? > The most efficient solution is to detect the duplicate request, and avoid all > of > the processing overhead of generating a response that must be discarded. > > No change to the MAD protocol is being proposed. Ib_free_recv_mad() already > exists, and must be called by each client. The only change being proposed is > that until ib_free_recv_mad() is called, another message with the same TID, > SGID, and mgmt class is treated as a duplicate. I believe that this is > consistent with C13-18.1.1. C13-18.1.1 defines a new operation. Isn't the case you are describing is responding to an existing operation ? > >same request? If the response was lost the first time, eating the 2nd > >MAD without sending a response will result in another timeout and a > >3rd MAD... so maybe the recipient remembers the response and sends it > > The proposal is to only discard duplicate requests while a response to the > first > request is being generated. Just because a client sends a request 3 times > before we can send a response doesn't mean that we need to send 3 responses. > Such an implementation is suboptimal, and the responses that are of most > concern > use RMPP anyway. > > >Really, it's up to the MAD client to deal with duplicates in its own > >way. > > A client is still restricted from sending a duplicate response while a > previous > response is in progress. RMPP cannot handle this case. Why not ? Wouldn't the second response not match anything in the client on the request side ? -- 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] RFC: detecting duplicate MAD requests
On Fri, 2006-04-28 at 18:20, Sean Hefty wrote: > Today, a request MAD received by the MAD layer is handed to a client. The > client processes the MAD, and generates a response. If the client is slow to > process the MAD, the request may have been resent. The duplicate request is > also handed to the client. The result is that clients perform duplicate > processing of the MAD or must detect the duplicates themselves. > > I'd like to propose that the MAD layer detect duplicate requests. After a > request MAD has been handed to a client, its context would be maintained until > the user calls ib_free_recv_mad(), allowing duplicate requests to be > discarded. There's still a window here depending on when free MAD is called versus when the response gets back to the original requester. > One drawback to this approach are that the MAD layer may discard a MAD as a > duplicate that wasn't, I suppose this depends on how the duplicate discard works. Are you envisioning a specific scenario here ? > but I'm not sure if this would happen in practice. A > second drawback is that the receive MAD would need to be kept around until the > send completed (as opposed to the send started). Is this to handle the case where free MAD is called prior to the send completing ? Is this on the response side only ? -- Hal > Finally, a way would need to be found for when to call ib_free_recv_mad() for > userspace clients. > > - 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] RFC: detecting duplicate MAD requests
On Fri, 2006-04-28 at 18:44, Sean Hefty wrote: > Sean Hefty wrote: > > I'd like to propose that the MAD layer detect duplicate requests. After a > > request MAD has been handed to a client, its context would be maintained > > until > > the user calls ib_free_recv_mad(), allowing duplicate requests to be > > discarded. > > I should add that this also provides context that the MAD layer can use when > performing DS RMPP. On the initiator side, DS RMPP would be detected by an > RMPP > request that expected a response. (This assumes that the response is also > RMPP.) Aren't there 3 cases possible here: (1) non RMPP request/RMPP response (e.g. SA GetTable for one), (2) RMPP request/RMPP response (e.g. SA GetMulti), and (3) RMPP request/non RMPP response (I don't think this currently exists but may be mistaken). Are all handled on the initiator/requester side ? Are the changes only for case (2) ? > On the responder side, DS RMPP is detected when an RMPP response is sent > in response to an RMPP request. The responder side sounds more straightforward. -- 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
[openib-general] re RDS missing features
Can you elaborate on each of the features, specifically the following points are of interest to us: +1 so you running Oracle Loopback traffic over RDS sockets? if yes, what the issue here? the openib CMA supports listen/connect on loopback addresses (eg 127.0.0.1 or IPoIB local address) +2 by failover, are you referring to APM? that is failover between IB pathes to/from the same HCA over which the original connection/QP was established or you are talking on failover between HCAs +3 is the no support for /proc like for RDS an issue to run crload or demo Oracle (that is specific tuning and usage of non defaults is needed for any/optimal operation) Or. [openfabrics-ewg] Before we can start testing - we needto ensure that RDS is fully ported. Pandit, Ranjit rpandit at silverstorm.com Following features are yet to be implemented in OpenFabric Rds: 1. Failover 2. Loopback connections 3. support for /proc fs like Rds config, stats and info. Ranjit ___ 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 04/12] SRP: Changing ibsrpdm
On Mon, May 01, 2006 at 05:04:58PM +0300, Michael S. Tsirkin wrote: > > why _irq and not _irqsave? Are you sure this code can't ever be called > > with interrupts off via some other path? > > Given the mutex_lock above, this better be true. Good point, but _irq instinctively makes me worried. Cheers, Muli ___ 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 04/12] SRP: Changing ibsrpdm
Quoting r. Muli Ben-Yehuda <[EMAIL PROTECTED]>:
> > static ssize_t srp_create_target(struct class_device *class_dev,
> > const char *buf, size_t count)
> > {
> > struct srp_host *host =
> > container_of(class_dev, struct srp_host, class_dev);
> > struct Scsi_Host *target_host;
> > - struct srp_target_port *target;
> > + struct srp_target_port *target, *existing_target = NULL;
> > int ret;
> > int i;
> >
> > + /* first check if the target already exists */
> > +
> > + mutex_lock(&host->target_mutex);
> > + ret = srp_find_target(buf, host, &existing_target);
> > + if (ret)
> > + goto unlock_mutex;
> > +
> > + if (existing_target) {
> > + /* target already exists */
> > + spin_lock_irq(existing_target->scsi_host->host_lock);
>
> why _irq and not _irqsave? Are you sure this code can't ever be called
> with interrupts off via some other path?
Given the mutex_lock above, this better be true.
--
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] [PATCH 06/12] SRP: Changing ibsrpdm
On Mon, May 01, 2006 at 02:28:48PM +0300, Ishai Rabinovitz wrote:
>
> Support a display of list of target from user level.
>
> Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
> Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
> ===
> --- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-21
> 01:13:04.0 +0300
> +++ last_stable/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-21
> 03:56:05.0 +0300
> @@ -1730,6 +1730,63 @@ end:
>
> static CLASS_DEVICE_ATTR(remove_target, S_IWUSR, NULL, srp_remove_target);
>
> +#define TARGET_INFO_BUF_SIZE 126
> +
> +static ssize_t list_targets(struct class_device *class_dev, char *buf)
> +{
> + struct srp_host *host =
> + container_of(class_dev, struct srp_host, class_dev);
> + struct srp_target_port *target;
> + int printed=0, ret;
> +
> + mutex_lock(&host->target_mutex);
> + list_for_each_entry(target, &host->target_list, list)
Can this race with list addition / removal? I saw that you removed the
lock in an earlier patch?
> + if (target->state == SRP_TARGET_LIVE) {
You'd have an easier time with the indentation if you'd do
if (target->state != SRP_TARGET_LIVE)
continue;
here
> + ret = sprintf(buf+printed,
> + "id_ext=%016llx,ioc_guid=%016llx,"
> + "dgid=%04x%04x%04x%04x%04x%04x%04x%04x,"
> + "pkey=%04x,service_id=%016llx\n",
> + (unsigned long long)
> + be64_to_cpu(target->id_ext),
> + (unsigned long long)
> + be64_to_cpu(target->ioc_guid),
> + (int) be16_to_cpu(*(__be16 *)
> + &target->path.dgid.raw[0]),
> + (int) be16_to_cpu(*(__be16 *)
> + &target->path.dgid.raw[2]),
> + (int) be16_to_cpu(*(__be16 *)
> + &target->path.dgid.raw[4]),
> + (int) be16_to_cpu(*(__be16 *)
> + &target->path.dgid.raw[6]),
> + (int) be16_to_cpu(*(__be16 *)
> + &target->path.dgid.raw[8]),
> + (int) be16_to_cpu(*(__be16 *)
> + &target->path.dgid.raw[10]),
> + (int) be16_to_cpu(*(__be16 *)
> + &target->path.dgid.raw[12]),
> + (int) be16_to_cpu(*(__be16 *)
> + &target->path.dgid.raw[14]),
This is pretty horrible - could you use show_dgid() here?
Cheers,
Muli
___
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 04/12] SRP: Changing ibsrpdm
On Mon, May 01, 2006 at 02:27:39PM +0300, Ishai Rabinovitz wrote:
>
> Do not add the same target twice.
>
> Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
> Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
> ===
> --- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-25
> 15:17:34.0 +0300
> +++ last_stable/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-25
> 15:19:37.0 +0300
> @@ -1478,7 +1478,8 @@ static int srp_parse_options(const char
> printk(KERN_WARNING PFX "bad max sect parameter
> '%s'\n", p);
> goto out;
> }
> - target->scsi_host->max_sectors = token;
> + if (target->scsi_host != NULL)
> + target->scsi_host->max_sectors = token;
> break;
This chunk does not look related to the rest. Is a NULL
target->scsi_host legal here? if not, the check should be removed as
we'd rather take an oops here than hide the problem behind the NULL
pointer check.
> +/* srp_find_target - If the target exists return it in target,
> + otherwise target is set to NULL.
> + host->target_mutex should be hold */
Please use the usual kernel
/*
* stuff
*/
style for multi line comments.
> +static int srp_find_target(const char *buf, struct srp_host *host,
> +struct srp_target_port **target)
> +{
> + struct srp_target_port *target_to_find, *curr_target;
> + int ret, i;
> +
> + target_to_find = kzalloc(sizeof *target_to_find, GFP_KERNEL);
> + ret = srp_parse_options(buf, target_to_find);
> + if (ret)
> + goto free;
> +
> + list_for_each_entry(curr_target, &host->target_list, list)
> + if (target_to_find->ioc_guid == curr_target->ioc_guid &&
> + target_to_find->id_ext == curr_target->id_ext &&
> + target_to_find->path.pkey == curr_target->path.pkey &&
> + target_to_find->service_id == curr_target->service_id) {
> + for (i = 0; i < 16; ++i)
> + if (target_to_find->path.dgid.raw[i] !=
> curr_target->path.dgid.raw[i])
> + break;
The conditional and check here probably deserves an inline helper
called same_target() or some such.
> + if (i == 16) {
> + *target = curr_target;
> + goto free;
> + }
> + }
> +
> + *target = NULL;
> +
> +free:
> + kfree(target_to_find);
> + return 0;
We always return 0 - either this should return void, or you meant to
return ret here instead of 0?
> +}
> +
> static ssize_t srp_create_target(struct class_device *class_dev,
>const char *buf, size_t count)
> {
> struct srp_host *host =
> container_of(class_dev, struct srp_host, class_dev);
> struct Scsi_Host *target_host;
> - struct srp_target_port *target;
> + struct srp_target_port *target, *existing_target = NULL;
> int ret;
> int i;
>
> + /* first check if the target already exists */
> +
> + mutex_lock(&host->target_mutex);
> + ret = srp_find_target(buf, host, &existing_target);
> + if (ret)
> + goto unlock_mutex;
> +
> + if (existing_target) {
> + /* target already exists */
> + spin_lock_irq(existing_target->scsi_host->host_lock);
why _irq and not _irqsave? Are you sure this code can't ever be called
with interrupts off via some other path?
Cheers,
Muli
___
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: possible bug in kmem_cache related code
Pekka Enberg wrote: On Fri, 2006-04-28 at 21:24 +0200, Or Gerlitz wrote: Yes, i can reproduce this at will, no local modifications, my system is amd dual x86_64, i have attached my .config to the first email of this thread, and also mentioned that some CONFIG_DEBUG_ options are set, including one related to slab debugging. Yeah, arch/um/. Unfortunately I don't have a SMP box, so I probably can't reproduce this. You could try git bisect to isolate the offending changeset. mmm, I might be able to do git bisection later this week or next week. However, for the mean time can more people of the openib and open iscsi communities set 2.6.17-rcX to see that the issue reproduces with my synthetic module and with ib/iscsi code (you know this kernel will be out in few weeks from now...) 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
Re: [openib-general] [PATCHE 02/12] SRP: changing ibsrpdm
On Mon, May 01, 2006 at 02:25:46PM +0300, Ishai Rabinovitz wrote:
>
> Move the destruction of the host and the removal from a list to a function.
>
> Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
>
> Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
> ===
> --- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-23
> 14:08:03.0 +0300
> +++ last_stable/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-24
> 10:47:00.0 +0300
> @@ -344,6 +344,16 @@ static void srp_disconnect_target(struct
> wait_for_completion(&target->done);
> }
>
> +static void destruct_scsi_host_and_target(struct srp_target_port *target,
> int disconnect_target)
> +{
> + scsi_remove_host(target->scsi_host);
> + if (disconnect_target)
> + srp_disconnect_target(target);
> + ib_destroy_cm_id(target->cm_id);
> + srp_free_target_ib(target);
> + scsi_host_put(target->scsi_host);
> +}
> +
> static void srp_remove_work(void *target_ptr)
> {
> struct srp_target_port *target = target_ptr;
> @@ -357,10 +374,7 @@ static void srp_remove_work(void *target
> list_del(&target->list);
> mutex_unlock(&target->srp_host->target_mutex);
>
> - scsi_remove_host(target->scsi_host);
> - ib_destroy_cm_id(target->cm_id);
> - srp_free_target_ib(target);
> - scsi_host_put(target->scsi_host);
> + destruct_scsi_host_and_target(target, 0);
Is not disconnecting from the target here actually the right thing to
do? considering we're then destroying the target's queue pairs and
freeing it?
Cheers,
Muli
___
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 5/6] iser RDMA CM (CMA) and IB verbsinteraction
Sean Hefty wrote:
+static void iser_disconnected_handler(struct rdma_cm_id *cma_id)
+{
+ struct iser_conn *ib_conn;
+
+ ib_conn = (struct iser_conn *)cma_id->context;
+ ib_conn->disc_evt_flag = 1;
+
+ /* If this event is unsolicited this means that the conn is being */
+ /* terminated asynchronously from the iSCSI layer's perspective. */
+ if (atomic_read(&ib_conn->state) == ISER_CONN_PENDING) {
+ atomic_set(&ib_conn->state, ISER_CONN_DOWN);
+ wake_up_interruptible(&ib_conn->wait);
+ } else {
+ if (atomic_read(&ib_conn->state) == ISER_CONN_UP) {
+ atomic_set(&ib_conn->state, ISER_CONN_TERMINATING);
+ iscsi_conn_failure(ib_conn->iser_conn->iscsi_conn,
+ ISCSI_ERR_CONN_FAILED);
+ }
+ /* Complete the termination process if no posts are pending */
+ if ((atomic_read(&ib_conn->post_recv_buf_count) == 0) &&
+ (atomic_read(&ib_conn->post_send_buf_count) == 0)) {
+ atomic_set(&ib_conn->state, ISER_CONN_DOWN);
+ wake_up_interruptible(&ib_conn->wait);
+ }
+ }
Are there races here between reading ib_conn->state and setting it? Could it
have changed in between the atomic_read() and atomic_set()?
It seems that indeed a race is possible here, i am rethinking now on the
implementation of the ib connection states moves, thanks for pointing this.
+ src = (struct sockaddr *)src_addr;
+ dst = (struct sockaddr *)dst_addr;
+ err = rdma_resolve_addr(ib_conn->cma_id, src, dst, 1000);
+ if (err) {
+ iser_err("rdma_resolve_addr failed: %d\n", err);
+ goto addr_failure;
+ }
+
+ if (!non_blocking) {
+ wait_event_interruptible(ib_conn->wait,
+atomic_read(&ib_conn->state) != ISER_CONN_PENDING);
+
+ if (atomic_read(&ib_conn->state) != ISER_CONN_UP) {
+ err = -EIO;
+ goto connect_failure;
+ }
+ }
+
+ mutex_lock(&ig.connlist_mutex);
+ list_add(&ib_conn->conn_list, &ig.connlist);
+ mutex_unlock(&ig.connlist_mutex);
Not sure if there's a race here or not, but rdma_resolve_addr() will result in a
callback from a separate thread. That callback could occur before the ib_conn
is added to the ig.connlist. Do you assume that ib_conn is in the connlist in
any of the callbacks?
No, i don't assume this in the callbacks. ib_conn is inserted to the
list in iser_connect and being lookup-ed in ep_poll, conn_bind and
ep_disconnect where each subset of the latter three functions are
serialized are iser_connect since they are called by the same user space
process (iscsid, via iscsi netlink u/k IPC mechanism).
However, in a review i have made to fully answer your question i have
found a possible double call to iser_conn_release where the fix below
handles it.
r6802 | ogerlitz | 2006-05-01 12:27:12 +0300 (Mon, 01 May 2006) | 5 lines
move the ib conn deletion from the global connlist to iser_conn_release,
fix ep_disconnect to call conn_terminate or conn_release but not both.
Signed-off-by: Or Gerlitz <[EMAIL PROTECTED]>
Index: iser_verbs.c
===
--- iser_verbs.c(revision 6761)
+++ iser_verbs.c(revision 6802)
@@ -301,10 +301,6 @@ void iser_conn_terminate(struct iser_con
wait_event_interruptible(ib_conn->wait,
(atomic_read(&ib_conn->state) ==
ISER_CONN_DOWN));
- mutex_lock(&ig.connlist_mutex);
- list_del(&ib_conn->conn_list);
- mutex_unlock(&ig.connlist_mutex);
-
iser_conn_release(ib_conn);
}
@@ -463,6 +459,7 @@ int iser_conn_init(struct iser_conn **ib
atomic_set(&ib_conn->post_send_buf_count, 0);
INIT_WORK(&ib_conn->comperror_work, iser_comp_error_worker,
ib_conn);
+ INIT_LIST_HEAD(&ib_conn->conn_list);
*ibconn = ib_conn;
return 0;
@@ -541,6 +538,10 @@ void iser_conn_release(struct iser_conn
BUG_ON(atomic_read(&ib_conn->state) != ISER_CONN_DOWN);
+ mutex_lock(&ig.connlist_mutex);
+ list_del(&ib_conn->conn_list);
+ mutex_unlock(&ig.connlist_mutex);
+
iser_free_ib_conn_res(ib_conn);
ib_conn->device = NULL;
/* on EVENT_ADDR_ERROR there's no device yet for this conn */
Index: iscsi_iser.c
===
--- iscsi_iser.c(revision 6761)
+++ iscsi_iser.c(revision 6802)
@@ -680,8 +680,8 @@ iscsi_iser_ep_disconnect(__u64 ep_handle
if (atomic_read(&ib_conn->state) == ISER_CONN_UP)
iser_conn_terminate(ib_conn);
-
- iser_conn_re
Re: [openib-general] [PATCH 5/6] iser RDMA CM (CMA) and IB verbsinteraction
Sean Hefty wrote: +static int iser_free_device_ib_res(struct iser_device *device) Can you eliminate the return code? +struct iser_device *iser_device_find_by_ib_device(struct rdma_cm_id *cma_id) + if (device == NULL) + goto end; goto out; // see below out: both fixes are committed in r761 Or. r6761 | ogerlitz | 2006-04-30 15:35:15 +0300 (Sun, 30 Apr 2006) | 5 lines made iser_free_device_ib_res() void, changed the goto label of iser_device_find_by_ib_device() to be named "out" instead of "end". Signed-off-by: Or Gerlitz <[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] [PATCH] SRP: Avoid a potential deadlock
Hi, I think there is a potential deadlock when disconnecting from the CM. Roland, can you look at this patch and check if it is needed. Thanks Ishai -- Avoid a potential dead-lock. In srp_disconnect_target there is a call to ib_send_cm_dreq and a wait for completion If when getting DREP there is no comp no one will end this wait Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]> Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c === --- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-04-17 10:03:08.0 +0300 +++ last_stable/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-17 10:06:19.0 +0300 @@ -1194,6 +1194,7 @@ static int srp_cm_handler(struct ib_cm_i break; case IB_CM_DREP_RECEIVED: + comp = 1; break; case IB_CM_TIMEWAIT_EXIT: -- Ishai Rabinovitz ___ 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 12/12] SRP: Changing ibsrpdm
The query can be improved if working against OpenSM that supports
the option to ask about a certain bit in the capability mask.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/src/userspace/srptools/src/srp-dm.c
===
--- last_stable.orig/src/userspace/srptools/src/srp-dm.c2006-04-21
06:26:25.0 +0300
+++ last_stable/src/userspace/srptools/src/srp-dm.c 2006-04-21
06:30:36.0 +0300
@@ -97,10 +97,16 @@ static inline uint64_t htonll(uint64_t x
#define SIZE_OF_QUERY_RESPONSE (1 << 18)
+#define SM_SUPPORTS_QUERY_OF_PART_OF_CAP_MASK_BIT_MASK (1 << 13)
+
+#define TEST_ONLY_SET_BIT_BIT_MASK (1 << 31)
+
#define N_COMP_MASK_NODE_TYPE htonll(1 << 4);
#define N_COMP_MASK_LID htonll(1);
+#define N_COMP_MASK_CAPABILITY_MASK htonll(1 << 7);
+
#define INITIAL_SIZE_OF_TARGET_TABLE 10
#define SLEEP_TIME 60
@@ -180,8 +186,6 @@ static void empty_set(targets_set *set)
static void destroy_set(targets_set *set)
{
- int i;
-
empty_set(set);
free(set->array);
}
@@ -679,6 +683,63 @@ static int get_port_info(int fd, uint32_
return 0;
}
+int get_class_port_info(int fd, uint32_t agent[2], uint16_t dlid,
+ int *is_mask_match_supported)
+{
+ struct ib_user_mad out_mad, in_mad;
+ struct srp_dm_rmpp_sa_mad *out_sa_mad, *in_sa_mad;
+ struct srp_dm_mad *in_dm_mad;
+ struct srp_dm_class_port_info *class_port_info;
+
+ in_sa_mad = (void *) in_mad.data;
+ in_dm_mad = (void *) in_mad.data;
+ out_sa_mad = (void *) out_mad.data;
+
+ init_srp_dm_mad(&out_mad, agent[1], sm_lid,
SRP_DM_ATTR_CLASS_PORT_INFO, 0);
+
+ out_sa_mad->mgmt_class= SRP_MGMT_CLASS_SA;
+ out_sa_mad->class_version = 2;
+
+ if (send_and_get(fd, &out_mad, &in_mad, 0) < 0)
+ return -1;
+
+/* TODO: to handle forwarding */
+ class_port_info = (void *) in_sa_mad->data;
+ *is_mask_match_supported =
+ !!(ntohs(class_port_info->cap_mask) &
+ SM_SUPPORTS_QUERY_OF_PART_OF_CAP_MASK_BIT_MASK);
+
+ return 0;
+}
+
+int get_node_info(int fd, uint32_t agent[2], uint16_t dlid, uint64_t *n_guid)
+{
+ struct ib_user_mad out_mad, in_mad;
+ struct srp_dm_rmpp_sa_mad *out_sa_mad, *in_sa_mad;
+ struct srp_dm_mad *in_dm_mad;
+ struct srp_sa_node_rec *node_info;
+
+ in_sa_mad = (void *) in_mad.data;
+ in_dm_mad = (void *) in_mad.data;
+ out_sa_mad = (void *) out_mad.data;
+
+ init_srp_dm_mad(&out_mad, agent[1], sm_lid, SRP_SA_ATTR_NODE, 0);
+
+ out_sa_mad->mgmt_class= SRP_MGMT_CLASS_SA;
+ out_sa_mad->class_version = 2;
+ out_sa_mad->comp_mask = htonll((uint64_t)1); /* LID */
+ node_info = (void *) out_sa_mad->data;
+ node_info->lid= htons(dlid);
+
+ if (send_and_get(fd, &out_mad, &in_mad, 0) < 0)
+ return -1;
+
+ node_info = (void *) in_sa_mad->data;
+ *n_guid = node_info->port_guid;
+
+ return 0;
+}
+
static int get_port_list(int fd, uint32_t agent[2])
{
uint8_t in_mad_space[SIZE_OF_QUERY_RESPONSE];
@@ -686,19 +747,11 @@ static int get_port_list(int fd, uint32_
struct srp_dm_rmpp_sa_mad *out_sa_mad, *in_sa_mad;
struct srp_sa_node_rec *node;
ssize_t len;
- char val[64];
int size;
int i;
uint64_t subnet_prefix;
int isdm;
- if (read_file(port_sysfs_path, "sm_lid", val, sizeof val) < 0) {
- pr_err("Couldn't read SM LID\n");
- return -1;
- }
-
- sm_lid = strtol(val, NULL, 0);
-
in_sa_mad = (void *) in_mad->data;
out_sa_mad = (void *) out_mad.data;
@@ -762,6 +815,57 @@ static int get_existing_targets()
return 0;
}
+int get_port_list_new(int fd, uint32_t agent[2])
+{
+ uint8_t in_mad_space[SIZE_OF_QUERY_RESPONSE];
+ struct ib_user_mad out_mad, *in_mad=(void *) in_mad_space;
+ struct srp_dm_rmpp_sa_mad *out_sa_mad, *in_sa_mad;
+ struct srp_sa_port_info_rec *port_info;
+ ssize_t len;
+ int size;
+ int i;
+ uint64_t subnet_prefix;
+ uint16_t lid;
+ uint64_t guid;
+
+ in_sa_mad = (void *) in_mad->data;
+ out_sa_mad = (void *) out_mad.data;
+
+ init_srp_dm_mad(&out_mad, agent[1], sm_lid, SRP_SA_ATTR_PORT_INFO,
+ TEST_ONLY_SET_BIT_BIT_MASK);
+
+ out_sa_mad->mgmt_class = SRP_MGMT_CLASS_SA;
+ out_sa_mad->method = SRP_SA_METHOD_GET_TABLE;
+ out_sa_mad->class_version = 2;
+ out_sa_mad->comp_mask = N_COMP_MASK_CAPABILITY_MASK;
+ port_info = (void *) out_sa_mad->data;
+ port_info->capability_mask = htonl(IS_
[openib-general] [PATCH 11/12] SRP: Changing ibsrpdm
Add -l option to ibsrpdm.
This option activates a daemon that queries for the targets in a loop and
tells ib_srp about new target that appears and old target that disappears.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/src/userspace/srptools/src/srp-dm.c
===
--- last_stable.orig/src/userspace/srptools/src/srp-dm.c2006-04-21
04:47:54.0 +0300
+++ last_stable/src/userspace/srptools/src/srp-dm.c 2006-04-21
05:16:11.0 +0300
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include "ib_user_mad.h"
#include "srp-dm.h"
@@ -49,17 +50,39 @@ static uint32_t tid = 1;
static int cmd = 0;
static int verbose = 0;
+static int loop= 0;
+static int add_target_fd;
+static int remove_target_fd;
+static char *list_targets_path;
+
+#define pr_log(arg...) \
+ do {\
+ if (verbose) { \
+ if (loop) \
+ syslog(LOG_WARNING, arg); \
+ else if (!cmd) \
+ printf(arg);\
+ } \
+ } while (0)
#define pr_human(arg...) \
do {\
- if (!cmd) \
+ if (!cmd && !loop) \
printf(arg);\
} while (0)
#define pr_cmd(arg...) \
do {\
- if (cmd)\
- printf(arg);\
+ if (cmd && !loop) \
+ printf(arg);\
+ } while (0)
+
+#define pr_err(arg...) \
+ do {\
+ if (loop) \
+ syslog(LOG_WARNING, arg); \
+ else\
+ fprintf(stderr, arg); \
} while (0)
#if __BYTE_ORDER == __LITTLE_ENDIAN
@@ -78,11 +101,106 @@ static inline uint64_t htonll(uint64_t x
#define N_COMP_MASK_LID htonll(1);
+#define INITIAL_SIZE_OF_TARGET_TABLE 10
+
+#define SLEEP_TIME 60
+
+static int size_of_target_table = INITIAL_SIZE_OF_TARGET_TABLE;
+
+/* Implementaion of target set in an array.
+* Assumption: there will be small number of targets
+* TODO: If this assumption does not hold,
+*change the implemantaion to a hash or a tree
+*/
+
+typedef struct {
+ char **array;
+ unsigned int next_index;
+ unsigned int size;
+} targets_set;
+
+static int create_set(targets_set *set)
+{
+ set->next_index = 0;
+ set->size = size_of_target_table;
+ set->array = calloc(set->size, sizeof(char *));
+ if (set->array == NULL) {
+ perror("calloc:");
+ return -1;
+ }
+
+ return 0;
+}
+
+static int add_to_set(targets_set *set, char *target_info)
+{
+ if (set->next_index == set->size) {
+ if (set->size == size_of_target_table)
+ size_of_target_table *= 2;
+ set->size = size_of_target_table;
+ set->array = realloc(set->array, set->size * sizeof(char *));
+ if (set->array == NULL) {
+ pr_err("realloc: %s\n", strerror(errno));
+ return -1;
+ }
+ }
+ set->array[set->next_index] = strdup(target_info);
+ if (set->array[set->next_index] == NULL) {
+ pr_err("strdup: %s\n", strerror(errno));
+ return -1;
+ }
+ ++set->next_index;
+
+ return 0;
+}
+
+static int remove_from_set(targets_set *set, char *target_info)
+{
+ int i;
+
+ for (i = 0; i < set->next_index; ++i)
+ if (!strcmp(set->array[i], target_info)) {
+ free(set->array[i]);
+ set->array[i] = set->array[set->next_index];
+ --set->next_index;
+ return 0;
+ }
+
+ return -1;
+}
+
+static void empty_set(targets_set *set)
+{
+ int i;
+
+ for (i = 0; i < set->next_index; ++i)
+ free(set->array[i]);
+ set->next_index = 0;
+}
+
+static void destroy_set(targets_set *set)
+{
+ int i;
+
+ empty_set(set);
+ free(set->array);
+}
+
+/* for_each_entry_in_set(char *target, targets_set *set, int i) */
+#define for_each_entry_in_set(target, set, i) \
+ for (i = 0, target = set->array[i]; \
+i < set->next_index; \
+
[openib-general] [PATCH 10/12] SRP: Changing ibsrpdm
Add a function send_and_get that handles the communication and retries.
Reduce redundancy.
Increment TID on retry.
Bound the number of retries.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/src/userspace/srptools/src/srp-dm.c
===
--- last_stable.orig/src/userspace/srptools/src/srp-dm.c2006-04-21
01:35:10.0 +0300
+++ last_stable/src/userspace/srptools/src/srp-dm.c 2006-04-21
01:41:28.0 +0300
@@ -85,6 +85,36 @@ static void usage(const char *argv0)
fprintf(stderr, "Usage: %s [-vc] [-d ]\n", argv0);
}
+#define NUM_OF_RETRIES 3
+int send_and_get(int fd, struct ib_user_mad *out_mad,
+struct ib_user_mad *in_mad, long in_mad_size)
+{
+ int i, len, in_mad_real_size;
+ struct srp_dm_mad *out_dm_mad;
+
+ in_mad_real_size = (in_mad_size ? in_mad_size : sizeof(struct
ib_user_mad));
+ for (i = 0; i < NUM_OF_RETRIES; ++i)
+ {
+ len = write(fd, out_mad, sizeof(struct ib_user_mad));
+ if (len != sizeof(struct ib_user_mad)) {
+ fprintf(stderr, "write: %s\n", strerror(errno));
+ return -1;
+ }
+
+ len = read(fd, in_mad, in_mad_real_size);
+ if ((in_mad_size == 0 && len == in_mad_real_size) ||
+ (in_mad_size != 0 && len > 0))
+ return len;
+ else if (in_mad->hdr.status != ETIMEDOUT) {
+ fprintf(stderr, "%s/%d: read: %s\n", __func__,
__LINE__, strerror(errno));
+ return -1;
+ }
+ out_dm_mad = (void *) out_mad->data;
+ ((uint32_t *) &out_dm_mad->tid)[1] = tid++;
+ }
+ return -1;
+}
+
static int read_file(const char *dir, const char *file, char *buf, size_t size)
{
char *path;
@@ -234,19 +264,8 @@ static int set_class_port_info(int fd, u
((uint16_t *) cpi->trap_gid)[i] = htons(strtol(val + i * 5,
NULL, 16));
}
-again:
- if (write(fd, &out_mad, sizeof out_mad) != sizeof out_mad) {
- perror("write");
+ if (send_and_get(fd, &out_mad, &in_mad, 0) < 0)
return -1;
- }
-
- if (read(fd, &in_mad, sizeof in_mad) != sizeof in_mad) {
- if (in_mad.hdr.status == ETIMEDOUT)
- goto again;
- fprintf(stderr, "%s/%d: ", __func__, __LINE__);
- perror("read");
- return -1;
- }
in_dm_mad = (void *) in_mad.data;
if (in_dm_mad->status) {
@@ -266,19 +285,8 @@ static int get_iou_info(int fd, uint32_t
init_srp_dm_mad(&out_mad, agent[1], dlid, SRP_DM_ATTR_IO_UNIT_INFO, 0);
-again:
- if (write(fd, &out_mad, sizeof out_mad) != sizeof out_mad) {
- perror("write");
- return -1;
- }
-
- if (read(fd, &in_mad, sizeof in_mad) != sizeof in_mad) {
- if (in_mad.hdr.status == ETIMEDOUT)
- goto again;
- fprintf(stderr, "%s/%d: ", __func__, __LINE__);
- perror("read");
+ if (send_and_get(fd, &out_mad, &in_mad, 0) < 0)
return -1;
- }
in_dm_mad = (void *) in_mad.data;
if (in_dm_mad->status) {
@@ -300,19 +308,8 @@ static int get_ioc_prof(int fd, uint32_t
init_srp_dm_mad(&out_mad, agent[1], dlid,
SRP_DM_ATTR_IO_CONTROLLER_PROFILE, ioc);
-again:
- if (write(fd, &out_mad, sizeof out_mad) != sizeof out_mad) {
- perror("write");
+ if (send_and_get(fd, &out_mad, &in_mad, 0) < 0)
return -1;
- }
-
- if (read(fd, &in_mad, sizeof in_mad) != sizeof in_mad) {
- if (in_mad.hdr.status == ETIMEDOUT)
- goto again;
- fprintf(stderr, "%s/%d: ", __func__, __LINE__);
- perror("read");
- return -1;
- }
if (in_mad.hdr.status != 0) {
fprintf(stderr, "IO Controller Profile query timed out\n");
@@ -340,19 +337,8 @@ static int get_svc_entries(int fd, uint3
init_srp_dm_mad(&out_mad, agent[1], dlid, SRP_DM_ATTR_SERVICE_ENTRIES,
(ioc << 16) | (end << 8) | start);
-again:
- if (write(fd, &out_mad, sizeof out_mad) != sizeof out_mad) {
- perror("write");
+ if (send_and_get(fd, &out_mad, &in_mad, 0) < 0)
return -1;
- }
-
- if (read(fd, &in_mad, sizeof in_mad) != sizeof in_mad) {
- if (in_mad.hdr.status == ETIMEDOUT)
- goto again;
- fprintf(stderr, "%s/%d: ", __func__, __LINE__);
- perror("read");
- return -1;
- }
if (in_mad.hdr.status != 0) {
fprintf(stderr, "Service Entries query timed out\n");
@@ -486,20 +472,8 @@ static int get_port_info(int f
[openib-general] [PATCH 09/12] SRP: Changing ibsrpdm
alloca man page on my system says:
The alloca() function is machine and compiler dependent.
On many systems its implementation is buggy. Its use is discouraged.
Lets not use it.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/src/userspace/srptools/src/srp-dm.c
===
--- last_stable.orig/src/userspace/srptools/src/srp-dm.c2006-04-16
13:09:07.0 +0300
+++ last_stable/src/userspace/srptools/src/srp-dm.c 2006-04-16
13:11:17.0 +0300
@@ -510,7 +510,8 @@ again:
int get_port_list(int fd, uint32_t agent[2])
{
- struct ib_user_mad out_mad, *in_mad;
+ uint8_t in_mad_space[SIZE_OF_QUERY_RESPONSE];
+ struct ib_user_mad out_mad, *in_mad=(void *) in_mad_space;
struct srp_dm_rmpp_sa_mad *out_sa_mad, *in_sa_mad;
struct srp_sa_node_rec *node;
ssize_t len;
@@ -521,8 +522,6 @@ int get_port_list(int fd, uint32_t agent
uint64_t subnet_prefix;
int isdm;
- in_mad= alloca(SIZE_OF_QUERY_RESPONSE);
-
in_sa_mad = (void *) in_mad->data;
out_sa_mad = (void *) out_mad.data;
--
Ishai Rabinovitz
___
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 08/12] SRP: Changing ibsrpdm
Use constants for bits in masks. Improves readability.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/src/userspace/srptools/src/srp-dm.c
===
--- last_stable.orig/src/userspace/srptools/src/srp-dm.c2006-04-21
01:18:55.0 +0300
+++ last_stable/src/userspace/srptools/src/srp-dm.c 2006-04-21
03:41:39.0 +0300
@@ -70,6 +70,14 @@ static inline uint64_t ntohll(uint64_t x
static inline uint64_t htonll(uint64_t x) { return x; }
#endif
+#define IS_DM_MASK (1 << 19)
+
+#define SIZE_OF_QUERY_RESPONSE (1 << 18)
+
+#define N_COMP_MASK_NODE_TYPE htonll(1 << 4);
+
+#define N_COMP_MASK_LID htonll(1);
+
static char *sysfs_path = "/sys";
static void usage(const char *argv0)
@@ -474,7 +482,7 @@ static int get_port_info(int fd, uint32_
out_sa_mad->mgmt_class= SRP_MGMT_CLASS_SA;
out_sa_mad->class_version = 2;
- out_sa_mad->comp_mask = htonll(1); /* LID */
+ out_sa_mad->comp_mask = N_COMP_MASK_LID;
port_info = (void *) out_sa_mad->data;
port_info->endport_lid= htons(dlid);
@@ -495,7 +503,7 @@ again:
port_info = (void *) in_sa_mad->data;
*subnet_prefix = ntohll(port_info->subnet_prefix);
- *isdm = !!(ntohl(port_info->capability_mask) & (1 << 19));
+ *isdm = !!(ntohl(port_info->capability_mask) & IS_DM_MASK);
return 0;
}
@@ -519,7 +527,7 @@ static int get_port_list(int fd, uint32_
sm_lid = strtol(val, NULL, 0);
- in_mad= alloca(1 << 18);
+ in_mad= alloca(SIZE_OF_QUERY_RESPONSE);
in_sa_mad = (void *) in_mad->data;
out_sa_mad = (void *) out_mad.data;
@@ -529,7 +537,7 @@ static int get_port_list(int fd, uint32_
out_sa_mad->mgmt_class= SRP_MGMT_CLASS_SA;
out_sa_mad->method= SRP_SA_METHOD_GET_TABLE;
out_sa_mad->class_version = 2;
- out_sa_mad->comp_mask = htonll(1ul << 4); /* node type */
+ out_sa_mad->comp_mask = N_COMP_MASK_NODE_TYPE;
out_sa_mad->rmpp_version = 1;
out_sa_mad->rmpp_type = 1;
node = (void *) out_sa_mad->data;
@@ -541,7 +549,7 @@ again:
return -1;
}
- len = read(fd, in_mad, 1 << 18);
+ len = read(fd, in_mad, SIZE_OF_QUERY_RESPONSE);
if (len < 0) {
fprintf(stderr, "%s/%d: ", __func__, __LINE__);
perror("read");
--
Ishai Rabinovitz
___
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 07/12] SRP: Changing ibsrpdm
Remove trailing spaces and arranging tabs.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/src/userspace/srptools/src/srp-dm.c
===
--- last_stable.orig/src/userspace/srptools/src/srp-dm.c2006-04-21
03:54:05.0 +0300
+++ last_stable/src/userspace/srptools/src/srp-dm.c 2006-04-21
04:20:43.0 +0300
@@ -102,7 +102,6 @@ static int read_file(const char *dir, co
return len;
}
-
static int setup_port_sysfs_path(void) {
char *env;
char class_dev_path[256];
@@ -135,7 +134,7 @@ static int setup_port_sysfs_path(void) {
fprintf(stderr, "Couldn't read ibdev attribute\n");
return -1;
}
-
+
if (read_file(class_dev_path, "port", ibport, sizeof ibport) < 0) {
fprintf(stderr, "Couldn't read port attribute\n");
return -1;
@@ -385,7 +384,7 @@ static int do_port(int fd, uint32_t agen
pr_human("change ID: %04x\n", ntohs(iou_info.change_id));
pr_human("max controllers: 0x%02x\n", iou_info.max_controllers);
- if (verbose > 0)
+ if (verbose > 0)
for (i = 0; i < iou_info.max_controllers; ++i) {
pr_human("controller[%3d]: ", i + 1);
switch ((iou_info.controller_list[i / 2] >>
--
Ishai Rabinovitz
___
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 06/12] SRP: Changing ibsrpdm
Support a display of list of target from user level.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-04-21
01:13:04.0 +0300
+++ last_stable/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-21
03:56:05.0 +0300
@@ -1730,6 +1730,63 @@ end:
static CLASS_DEVICE_ATTR(remove_target, S_IWUSR, NULL, srp_remove_target);
+#define TARGET_INFO_BUF_SIZE 126
+
+static ssize_t list_targets(struct class_device *class_dev, char *buf)
+{
+ struct srp_host *host =
+ container_of(class_dev, struct srp_host, class_dev);
+ struct srp_target_port *target;
+ int printed=0, ret;
+
+ mutex_lock(&host->target_mutex);
+ list_for_each_entry(target, &host->target_list, list)
+ if (target->state == SRP_TARGET_LIVE) {
+ ret = sprintf(buf+printed,
+ "id_ext=%016llx,ioc_guid=%016llx,"
+ "dgid=%04x%04x%04x%04x%04x%04x%04x%04x,"
+ "pkey=%04x,service_id=%016llx\n",
+ (unsigned long long)
+ be64_to_cpu(target->id_ext),
+ (unsigned long long)
+ be64_to_cpu(target->ioc_guid),
+ (int) be16_to_cpu(*(__be16 *)
+ &target->path.dgid.raw[0]),
+ (int) be16_to_cpu(*(__be16 *)
+ &target->path.dgid.raw[2]),
+ (int) be16_to_cpu(*(__be16 *)
+ &target->path.dgid.raw[4]),
+ (int) be16_to_cpu(*(__be16 *)
+ &target->path.dgid.raw[6]),
+ (int) be16_to_cpu(*(__be16 *)
+ &target->path.dgid.raw[8]),
+ (int) be16_to_cpu(*(__be16 *)
+ &target->path.dgid.raw[10]),
+ (int) be16_to_cpu(*(__be16 *)
+ &target->path.dgid.raw[12]),
+ (int) be16_to_cpu(*(__be16 *)
+ &target->path.dgid.raw[14]),
+ be16_to_cpu(target->path.pkey),
+ (unsigned long long)
+ be64_to_cpu(target->service_id));
+ if (ret <= 0)
+ goto end;
+
+ printed += ret;
+
+ if (printed + TARGET_INFO_BUF_SIZE > PAGE_SIZE - 1)
+ break;
+ }
+
+ ret = printed;
+
+end:
+ mutex_unlock(&host->target_mutex);
+ return ret;
+}
+
+static CLASS_DEVICE_ATTR(list_targets, S_IRUGO, list_targets, NULL);
+
static ssize_t show_ibdev(struct class_device *class_dev, char *buf)
{
struct srp_host *host =
@@ -1789,6 +1846,8 @@ static struct srp_host *srp_add_port(str
goto err_class;
if (class_device_create_file(&host->class_dev,
&class_device_attr_remove_target))
goto err_class;
+ if (class_device_create_file(&host->class_dev,
&class_device_attr_list_targets))
+ goto err_class;
if (class_device_create_file(&host->class_dev,
&class_device_attr_ibdev))
goto err_class;
if (class_device_create_file(&host->class_dev, &class_device_attr_port))
--
Ishai Rabinovitz
___
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 05/12] SRP: Changing ibsrpdm
Support a remove of a target from user level.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-05-01
12:30:01.0 +0300
+++ last_stable/drivers/infiniband/ulp/srp/ib_srp.c 2006-05-01
12:36:22.0 +0300
@@ -960,10 +960,12 @@ static int srp_queuecommand(struct scsi_
long req_index;
int len;
- if (target->state == SRP_TARGET_CONNECTING)
+ if (target->state == SRP_TARGET_CONNECTING ||
+ target->state == SRP_TARGET_RECONNECTING)
goto err;
if (target->state == SRP_TARGET_DEAD ||
+ target->state == SRP_TARGET_DISCONNECTED ||
target->state == SRP_TARGET_REMOVED) {
scmnd->result = DID_BAD_TARGET << 16;
done(scmnd);
@@ -1254,6 +1256,7 @@ static int srp_send_tsk_mgmt(struct scsi
spin_lock_irq(target->scsi_host->host_lock);
if (target->state == SRP_TARGET_DEAD ||
+ target->state == SRP_TARGET_DISCONNECTED ||
target->state == SRP_TARGET_REMOVED) {
scmnd->result = DID_BAD_TARGET << 16;
goto out;
@@ -1359,6 +1362,7 @@ static ssize_t show_ioc_guid(struct clas
struct srp_target_port *target = host_to_target(class_to_shost(cdev));
if (target->state == SRP_TARGET_DEAD ||
+ target->state == SRP_TARGET_DISCONNECTED ||
target->state == SRP_TARGET_REMOVED)
return -ENODEV;
@@ -1371,6 +1375,7 @@ static ssize_t show_service_id(struct cl
struct srp_target_port *target = host_to_target(class_to_shost(cdev));
if (target->state == SRP_TARGET_DEAD ||
+ target->state == SRP_TARGET_DISCONNECTED ||
target->state == SRP_TARGET_REMOVED)
return -ENODEV;
@@ -1383,6 +1388,7 @@ static ssize_t show_pkey(struct class_de
struct srp_target_port *target = host_to_target(class_to_shost(cdev));
if (target->state == SRP_TARGET_DEAD ||
+ target->state == SRP_TARGET_DISCONNECTED ||
target->state == SRP_TARGET_REMOVED)
return -ENODEV;
@@ -1394,6 +1400,8 @@ static ssize_t show_dgid(struct class_de
struct srp_target_port *target = host_to_target(class_to_shost(cdev));
if (target->state == SRP_TARGET_DEAD ||
+ target->state == SRP_TARGET_DISCONNECTED ||
+ target->state == SRP_TARGET_DISCONNECTED ||
target->state == SRP_TARGET_REMOVED)
return -ENODEV;
@@ -1447,11 +1455,11 @@ static int srp_add_target(struct srp_hos
if (scsi_add_host(target->scsi_host, host->dev->dev->dma_device))
return -ENODEV;
- mutex_lock(&host->target_mutex);
list_add_tail(&target->list, &host->target_list);
- mutex_unlock(&host->target_mutex);
+ spin_lock_irq(target->scsi_host->host_lock);
target->state = SRP_TARGET_LIVE;
+ spin_unlock_irq(target->scsi_host->host_lock);
/* XXX: are we supposed to have a definition of SCAN_WILD_CARD ?? */
scsi_scan_target(&target->scsi_host->shost_gendev,
@@ -1642,7 +1650,6 @@ static ssize_t srp_create_target(struct
{
struct srp_host *host =
container_of(class_dev, struct srp_host, class_dev);
- struct Scsi_Host *target_host;
struct srp_target_port *target, *existing_target = NULL;
int ret;
int i;
@@ -1663,6 +1670,7 @@ static ssize_t srp_create_target(struct
buf);
ret = -EEXIST;
break;
+ case SRP_TARGET_RECONNECTING:
case SRP_TARGET_CONNECTING:
/* It is in the middle of reconnecting */
ret = -EALREADY;
@@ -1671,6 +1679,10 @@ static ssize_t srp_create_target(struct
/* It will be removed soon - create a new one */
case SRP_TARGET_REMOVED:
/* target is dead, create a new one */
+ existing_target = NULL;
+ break;
+ case SRP_TARGET_DISCONNECTED:
+ existing_target->state = SRP_TARGET_RECONNECTING;
break;
}
spin_unlock_irq(existing_target->scsi_host->host_lock);
@@ -1678,26 +1690,30 @@ static ssize_t srp_create_target(struct
goto unlock_mutex;
}
- /* really create the target */
- target_host = scsi_host_alloc(&srp_template,
- sizeof (struct srp_target_port));
- if (!target_host) {
- ret = -ENOMEM;
- goto unlock_mutex;
- }
-
- target_host->max_lun = SRP_MAX_LUN;
-
- target = host_to_target(target_host);
[openib-general] re cma upcalls serialization / disconnected event question
Hi Sean,
Can a ULP assume that cma callbacks for to the same CMA ID
are serialized?
Also and related to this, is it correct that ***always** before
DISCONNECTED event there will be one of {ESTABLISHED, REJECTED,
CONNECT_ERROR}?
I am talking on the active side and assuming there's no notification
on CONNECT_RESPONSE.
thanks,
Or.
/*
* Upon receiving a device removal event, users must destroy the associated
* RDMA identifier and release all resources allocated with the device.
*/
enum rdma_cm_event_type {
RDMA_CM_EVENT_ADDR_RESOLVED,
RDMA_CM_EVENT_ADDR_ERROR,
RDMA_CM_EVENT_ROUTE_RESOLVED,
RDMA_CM_EVENT_ROUTE_ERROR,
RDMA_CM_EVENT_CONNECT_REQUEST,
RDMA_CM_EVENT_CONNECT_RESPONSE,
RDMA_CM_EVENT_CONNECT_ERROR,
RDMA_CM_EVENT_UNREACHABLE,
RDMA_CM_EVENT_REJECTED,
RDMA_CM_EVENT_ESTABLISHED,
RDMA_CM_EVENT_DISCONNECTED,
RDMA_CM_EVENT_DEVICE_REMOVAL,
};
___
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 04/12] SRP: Changing ibsrpdm
Do not add the same target twice.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-04-25
15:17:34.0 +0300
+++ last_stable/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-25
15:19:37.0 +0300
@@ -1478,7 +1478,8 @@ static int srp_parse_options(const char
printk(KERN_WARNING PFX "bad max sect parameter
'%s'\n", p);
goto out;
}
- target->scsi_host->max_sectors = token;
+ if (target->scsi_host != NULL)
+ target->scsi_host->max_sectors = token;
break;
default:
@@ -1503,20 +1504,89 @@ out:
return ret;
}
+/* srp_find_target - If the target exists return it in target,
+ otherwise target is set to NULL.
+ host->target_mutex should be hold */
+static int srp_find_target(const char *buf, struct srp_host *host,
+ struct srp_target_port **target)
+{
+ struct srp_target_port *target_to_find, *curr_target;
+ int ret, i;
+
+ target_to_find = kzalloc(sizeof *target_to_find, GFP_KERNEL);
+ ret = srp_parse_options(buf, target_to_find);
+ if (ret)
+ goto free;
+
+ list_for_each_entry(curr_target, &host->target_list, list)
+ if (target_to_find->ioc_guid == curr_target->ioc_guid &&
+ target_to_find->id_ext == curr_target->id_ext &&
+ target_to_find->path.pkey == curr_target->path.pkey &&
+ target_to_find->service_id == curr_target->service_id) {
+ for (i = 0; i < 16; ++i)
+ if (target_to_find->path.dgid.raw[i] !=
curr_target->path.dgid.raw[i])
+ break;
+ if (i == 16) {
+ *target = curr_target;
+ goto free;
+ }
+ }
+
+ *target = NULL;
+
+free:
+ kfree(target_to_find);
+ return 0;
+}
+
static ssize_t srp_create_target(struct class_device *class_dev,
const char *buf, size_t count)
{
struct srp_host *host =
container_of(class_dev, struct srp_host, class_dev);
struct Scsi_Host *target_host;
- struct srp_target_port *target;
+ struct srp_target_port *target, *existing_target = NULL;
int ret;
int i;
+ /* first check if the target already exists */
+
+ mutex_lock(&host->target_mutex);
+ ret = srp_find_target(buf, host, &existing_target);
+ if (ret)
+ goto unlock_mutex;
+
+ if (existing_target) {
+ /* target already exists */
+ spin_lock_irq(existing_target->scsi_host->host_lock);
+ switch (existing_target->state) {
+ case SRP_TARGET_LIVE:
+ printk(KERN_WARNING PFX "target %s already exists\n",
+ buf);
+ ret = -EEXIST;
+ break;
+ case SRP_TARGET_CONNECTING:
+ /* It is in the middle of reconnecting */
+ ret = -EALREADY;
+ break;
+ case SRP_TARGET_DEAD:
+ /* It will be removed soon - create a new one */
+ case SRP_TARGET_REMOVED:
+ /* target is dead, create a new one */
+ break;
+ }
+ spin_unlock_irq(existing_target->scsi_host->host_lock);
+ if (ret)
+ goto unlock_mutex;
+ }
+
+ /* really create the target */
target_host = scsi_host_alloc(&srp_template,
sizeof (struct srp_target_port));
- if (!target_host)
- return -ENOMEM;
+ if (!target_host) {
+ ret = -ENOMEM;
+ goto unlock_mutex;
+ }
target_host->max_lun = SRP_MAX_LUN;
@@ -1533,7 +1603,7 @@ static ssize_t srp_create_target(struct
ret = srp_parse_options(buf, target);
if (ret)
- goto err;
+ goto err_put_scsi_host;
ib_get_cached_gid(host->dev, host->port, 0, &target->path.sgid);
@@ -1554,7 +1624,7 @@ static ssize_t srp_create_target(struct
ret = srp_create_target_ib(target);
if (ret)
- goto err;
+ goto err_put_scsi_host;
target->cm_id = ib_create_cm_id(host->dev, srp_cm_handler, target);
if (IS_ERR(target->cm_id)) {
@@ -1572,7 +1642,8 @@ static ssize_t srp_create_target(struct
if (ret)
[openib-general] [PATCH 03/12] SRP: Changing ibsrpdm
It is nicer to perform the init_work just before the call to schedule_work.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-04-17
10:57:59.0 +0300
+++ last_stable/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-18
02:26:29.0 +0300
@@ -828,8 +829,10 @@ static void srp_completion(struct ib_cq
wc.wr_id & SRP_OP_RECV ? "receive" : "send",
wc.status);
spin_lock_irqsave(target->scsi_host->host_lock, flags);
- if (target->state == SRP_TARGET_LIVE)
+ if (target->state == SRP_TARGET_LIVE) {
+ INIT_WORK(&target->work, srp_reconnect_work,
target);
schedule_work(&target->work);
+ }
spin_unlock_irqrestore(target->scsi_host->host_lock,
flags);
break;
}
@@ -1601,8 +1684,6 @@ static ssize_t srp_create_target(struct
target->scsi_host = target_host;
target->srp_host = host;
- INIT_WORK(&target->work, srp_reconnect_work, target);
-
for (i = 0; i < SRP_SQ_SIZE - 1; ++i)
target->req_ring[i].next = i + 1;
target->req_ring[SRP_SQ_SIZE - 1].next = -1;
--
Ishai Rabinovitz
___
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] [PATCHE 02/12] SRP: changing ibsrpdm
Move the destruction of the host and the removal from a list to a function.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-04-23
14:08:03.0 +0300
+++ last_stable/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-24
10:47:00.0 +0300
@@ -344,6 +344,16 @@ static void srp_disconnect_target(struct
wait_for_completion(&target->done);
}
+static void destruct_scsi_host_and_target(struct srp_target_port *target, int
disconnect_target)
+{
+ scsi_remove_host(target->scsi_host);
+ if (disconnect_target)
+ srp_disconnect_target(target);
+ ib_destroy_cm_id(target->cm_id);
+ srp_free_target_ib(target);
+ scsi_host_put(target->scsi_host);
+}
+
static void srp_remove_work(void *target_ptr)
{
struct srp_target_port *target = target_ptr;
@@ -357,10 +374,7 @@ static void srp_remove_work(void *target
list_del(&target->list);
mutex_unlock(&target->srp_host->target_mutex);
- scsi_remove_host(target->scsi_host);
- ib_destroy_cm_id(target->cm_id);
- srp_free_target_ib(target);
- scsi_host_put(target->scsi_host);
+ destruct_scsi_host_and_target(target, 0);
/* And another put to really free the target port... */
scsi_host_put(target->scsi_host);
}
@@ -1734,13 +1746,8 @@ static void srp_remove_one(struct ib_dev
flush_scheduled_work();
list_for_each_entry_safe(target, tmp_target,
-&host->target_list, list) {
- scsi_remove_host(target->scsi_host);
- srp_disconnect_target(target);
- ib_destroy_cm_id(target->cm_id);
- srp_free_target_ib(target);
- scsi_host_put(target->scsi_host);
- }
+&host->target_list, list)
+ destruct_scsi_host_and_target(target, 1);
ib_dereg_mr(host->mr);
ib_dealloc_pd(host->pd);
--
Ishai Rabinovitz
___
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] [PATCHE 01/12] SRP: changing ibsrpdm
Remove a redundant if
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-04-17
10:06:19.0 +0300
+++ last_stable/drivers/infiniband/ulp/srp/ib_srp.c 2006-04-17
10:11:24.0 +0300
@@ -1798,8 +1798,7 @@ static void srp_remove_one(struct ib_dev
list_for_each_entry_safe(target, tmp_target,
&host->target_list, list) {
spin_lock_irqsave(target->scsi_host->host_lock, flags);
- if (target->state != SRP_TARGET_REMOVED)
- target->state = SRP_TARGET_REMOVED;
+ target->state = SRP_TARGET_REMOVED;
spin_unlock_irqrestore(target->scsi_host->host_lock,
flags);
}
mutex_unlock(&host->target_mutex);
--
Ishai Rabinovitz
___
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 00/12] SRP: Changing ibsrpdm
Hi, I'm going to send 12 patches. 6 patches for the kernel, and 6 for the userspace ibsrpdm. The kernel patches avoid adding the same target twice, allow the removal of a target, and add a query about the connected targets. The userspace patches change ibsrpdm to a real daemon - that runs all the time and updates the kernel with the visible targets. Some of the kernel patches should be applied after Vu patches for fmr. The functionality of the changes can work without Vu's patches, but they are changing code in the same functions, so there may be some simple conflicts when applied without Vu's patches. -- Ishai Rabinovitz ___ 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] osm_switch.c : bug fix
Hi Ofer, On Mon, 2006-05-01 at 04:33, Ofer Gigi wrote: > Hi Hal, > > Bug fix: > In the function osm_switch_get_fwd_tbl_block in osm_switch.c we were > missing one block in case the maximum lid was the multiplication of > lids_per_block (==64). > Adding <= instead of < to fix the problem. > > Please apply to trunk and branch. Good catch. Thanks. Applied to trunk and 1.0 branch. -- Hal > Thanks > > Ofer G. > > Signed-off-by: Ofer Gigi <[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] OFED 1.0 release plan
Hi All, This is the release plan 1. RC3 – target: All components are in Schedule: done on Apr-10. 2. RC4 – target: features freeze – meaning all features and modules targeted for 1.0 release should be in. Schedule: May-4 (delayed from May-1 since some modules are not ready yet) Main changes from RC3 to RC4: 1. Bug fixes according to problems reported. 2. SDP - new code that Michael Tsirkin developed. 3. SRP - with new features: FMR, tunable parameters, SRP daemon 4. Open MPI – new package based on 1.1a3 5. RDS – new version from main trunk 6. Kernel code based on git 7. Standard network configuration 3. RC5 – target: bug fixes Schedule: May-16 Main changes from RC4 to RC5: 1. Bug fixes according to problems reported 2. Updated documentation 4. Final 1.0 release – after QA of all companies Schedule: May-29 Main changes from RC4 to RC5: 1. Showstopper bug fixes only 2. Final documentation Please send me any comments you have. Tziporet Koren Software Director Mellanox Technologies mailto: [EMAIL PROTECTED] Tel +972-4-9097200, ext 380 ___ 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
