From ips-bounces@ietf.org Thu May 1 06:51:23 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615F028C3CD; Thu, 1 May 2008 06:51:23 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B303A6E81 for ; Thu, 1 May 2008 06:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VePuAZl94EdB for ; Thu, 1 May 2008 06:51:15 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by core3.amsl.com (Postfix) with ESMTP id 4A5C228C463 for ; Thu, 1 May 2008 06:50:53 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i26so878444wxd.31 for ; Thu, 01 May 2008 06:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9ByT53T27wnosRhxJDbcc8qencQMirvLnrpZh/9WYEg=; b=hRoJCBXboq3Kn+Xs+KhEtKHQVuAqqrxJnkw8SNGslE2Xui/kzkNVpACa6HgzX5JzHJDSUwpfLxF1UfJAeJ37WLbLK6asrU58W5LiJhZqCgR7HylsAjFJPuVs5x76A8YFcbVPy802Kzwn8AtFWnBRZLtG0kWViZAMp4J9UZTesEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tkLYVNeEeLukJKAxmBLcy4wI1AeQCSAyH+XlddiLKWVKE/wVGvaaGN5plFgpjAEzOJ1MdxnpoPsQLwXMSeF21Z11NQSchggewOJ7GmP7a9dWz145koQZPG4hgB2JjnLT+N+zYTcHaplAYuPxqcU11KD1qN1jChTP4mbLykdY3iQ= Received: by 10.100.242.20 with SMTP id p20mr2896251anh.153.1209649855428; Thu, 01 May 2008 06:50:55 -0700 (PDT) Received: by 10.100.198.14 with HTTP; Thu, 1 May 2008 06:50:55 -0700 (PDT) Message-ID: <694d48600805010650l75c2f70bx662456ce85e7e9a5@mail.gmail.com> Date: Thu, 1 May 2008 16:50:55 +0300 From: "Eli Dorfman" To: "Pete Wyckoff" In-Reply-To: <20080429170516.GA8857@osc.edu> MIME-Version: 1.0 Content-Disposition: inline References: <4804B03C.6060507@voltaire.com> <694d48600804160122l1cc97b8aka8986ee6deb7dec8@mail.gmail.com> <20080416144830.GC23861@osc.edu> <694d48600804170413g4d54cd9g447abd345a1f6301@mail.gmail.com> <20080429170516.GA8857@osc.edu> Cc: stgt-devel , Roland Dreier , ofa-general , Mike Ko , ips@ietf.org, open-iscsi@googlegroups.com Subject: Re: [Ips] [ofa-general] Re: Calculating the VA in iSER header X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org On Tue, Apr 29, 2008 at 8:05 PM, Pete Wyckoff wrote: > dorfman.eli@gmail.com wrote on Thu, 17 Apr 2008 14:13 +0300: > > > On Wed, Apr 16, 2008 at 6:46 PM, Roland Dreier wrote: > > > > Agree with the interpretation of the spec, and it's probably a bit > > > > clearer that way too. But we have working initiators and targets > > > > that do it the "wrong" way. > > > > > > Yes... I guess the key question is whether there are any initiators that > > > do things the "right" way. > > > > > > > > > > 1. Flag day: all initiators and targets change at the same time. > > > > Will see data corruption if someone unluckily runs one or the other > > > > using old non-fixed code. > > > > > > Seems unacceptable to me... it doesn't make sense at all to break every > > > setup in the world just to be "right" according to the spec. > > > > This will break only when both initiator and target will use > > InitialR2T=No, which means allow unsolicited data. > > As far as I know, STGT is not very common (and its version in RHEL5.1 > > is considered experimental). Its default is also InitialR2T=Yes. > > Voltaire's iSCSI over iSER target also uses default InitialR2T=Yes. > > So it seems that nothing will break. > > I finally got a chance to look at this just now. I think you mean > default is InitialR2T=No above, which means no unsolicited data. > That is the default case, and true, the two different meanings > of the initiator-supplied VA coincide. InitialR2T=Yes means that R2T is required, hence no unsolicited data. Only is both sides, initiator and target agree on InitialR2T=No then first data burst is unsolicited. > > But you missed the impact of immediate data. We run with the > defaults (I think) that say the first write request packet should be > filled with a bit of the coming data stream. From iscsid.conf: > > # To enable immediate data (i.e., the initiator sends unsolicited data > # with the iSCSI command packet), uncomment the following line: > # > # The default is Yes > node.session.iscsi.ImmediateData = Yes > > Looking at the offset printed out by your patch, it is indeed > non-zero for the first RDMA read. Please correct me if I am > mistaken about this---you must have tested all four variations of > with and without the patches on initiator and target side, but I did > not. You are right about the ImmediateData=Yes. I really missed that, so after all this patch will break current target implementation and cause data corruption. I suggest to postpone this patch till we implement the iSER HELLO message and then add this patch with the corresponding target patch. This will allow current initiator to work with current target and new initiator work with new target. I still think we should do that since future iser implementation will probably rely on the spec. > > Hence I am still a bit unhappy about having to deal with the > fallout, with no way to detect it. For our local use, I'll keep an > older version of stgt in use until we switch to a new kernel, then > merge up the target side change. It is a bother, but I can deal > with it. For other institutions, this lockstep upgrade requirement > will not be obvious until they debug the resulting data corruption. > > Still, I do understand why it would be nice to conform to the spec, > and it is maybe a bit cleaner that way too. Maybe you can help with > the bug reports on stgt-devel during the transition, and maintain > and publish a patch to let it work with old kernels. > > -- Pete > _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu May 1 07:20:57 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA59A28C29D; Thu, 1 May 2008 07:20:57 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB3F73A6A11 for ; Thu, 1 May 2008 07:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrBrcFxGuM02 for ; Thu, 1 May 2008 07:20:55 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id B12CB28C29D for ; Thu, 1 May 2008 07:18:47 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so612807and.122 for ; Thu, 01 May 2008 07:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=0SmTc0X6IJcZsz3g5BxV4qqoH6uyGoSNphTMbpDfkIo=; b=P/N3mF0rFbDt+ulmMvX8ip0ouSlP89tN4lfthSjHcRzlmEm0VMUgVDJFa/sgRnnPsRoy887dnoBAmFH6j8eFLD67vJehRmJJ2S4dHQe2pVRq83l6DrQa/RRWCuI1WaDAzpRYLPiYiySWW46TEg5VaD1tf0GMAomINrwx7menhkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C35xP+Nn2UJ6KSwvrDm3FMqx5D6fg13l1fxMqex0m3pBHv5GPh2L6fSodyrIIJZylj2BPSQebOTx8WoD2BcJEUfRzO6EOfXC5BcNgHn6DGBg3qVUheaeSUqZIXnjWz/2R51oZWqG+DEP54OKTbK6irBfXk+zPi2fRtSZxljB6HY= Received: by 10.100.33.4 with SMTP id g4mr2961954ang.111.1209651525654; Thu, 01 May 2008 07:18:45 -0700 (PDT) Received: by 10.100.198.14 with HTTP; Thu, 1 May 2008 07:18:45 -0700 (PDT) Message-ID: <694d48600805010718n7f02a30ev38d35c50e926d02@mail.gmail.com> Date: Thu, 1 May 2008 17:18:45 +0300 From: "Eli Dorfman" To: "Ken Sandars" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <4804B03C.6060507@voltaire.com> <694d48600804160122l1cc97b8aka8986ee6deb7dec8@mail.gmail.com> <20080416144830.GC23861@osc.edu> <694d48600804170413g4d54cd9g447abd345a1f6301@mail.gmail.com> <20080429170516.GA8857@osc.edu> <39C75744D164D948A170E9792AF8E7CAF60D50@exil.voltaire.com> Cc: stgt-devel , Roland Dreier , Pete Wyckoff , ofa-general , Mike Ko , ips@ietf.org, open-iscsi@googlegroups.com Subject: Re: [Ips] [Stgt-devel] [ofa-general] Re: Calculating the VA iniSER header X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org On Thu, May 1, 2008 at 11:24 AM, Ken Sandars wrote: > > >> [Ken] It appears the current Linux iSER initiator does not send the HELLO > message when > > >> the connection transits to full feature phase. The stgt target also > ignores this > >> message (if it were to appear). > [Ken] The IBTA document does not mention the HELLO/HELLOREPLY messages. > Implementing this message exchange gives a distinction between the current > implementations > and those that will correctly calculate the write_va (as per Pete Wyckoff's > option 3). I agree. > > >> [Ken] Both of these implementations use a non-conformant iSER header > (they add > > >> write_va and read_va fields, which incidentally do not appear to be > used). Are > >> these changes documented anywhere in the IB domain, or are these > variations > >> needed for another reason? > > > > [Erez] Take a look at the iSER for IB annex: > > > http://www.infinibandta.org/members/spec/Annex_iSER.PDF > > [Ken] Ouch. That link requires a username/password. Looks like it is only > available to members > of the Infiniband Trade Association. Fortunately I gained access to it with > username "open" and > password "standard". ;-) > > [Ken] Neither of these implementations send or examine the iSER CM REQ/REP > message private data. > The document doesn't define what action to take when this message is > absent. Interestingly, > when the target reports that "ZBVA shall be used for this connection" and > "the target shall issue > Send with Invalidate as needed" then it appears the iSER header specified in > RFC5046 should be > used for control-type PDUs. Is there any plan to conform with the list of > requirements for IBTA > compliance? At the moment these capabilities (ZBVA, Send Invalidate) are not supported in the driver, though they seem to be supported by the ConnectX HCA. Hence, iSER implementation do not send/examine them. This may be added to the CM REQ/REP with the current defaults but in order to use these capabilities a code should be added to the HCA driver and iser. > > Cheers, > Ken > > ________________________________ > Hotmail on your mobile. Never miss another e-mail with _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon May 5 19:27:57 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78F093A6E3D; Mon, 5 May 2008 19:27:57 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D313A6E3D for ; Mon, 5 May 2008 19:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.472 X-Spam-Level: ** X-Spam-Status: No, score=2.472 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CN_BODY_49=0.02, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agZqS83dS2ye for ; Mon, 5 May 2008 19:27:54 -0700 (PDT) Received: from bay0-omc3-s33.bay0.hotmail.com (bay0-omc3-s33.bay0.hotmail.com [65.54.246.233]) by core3.amsl.com (Postfix) with ESMTP id 81CAE3A698B for ; Mon, 5 May 2008 19:27:54 -0700 (PDT) Received: from BAY135-W47 ([65.55.140.82]) by bay0-omc3-s33.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 May 2008 19:27:53 -0700 Message-ID: X-Originating-IP: [221.239.61.183] From: HUJason To: Date: Tue, 6 May 2008 10:27:53 +0800 Importance: Normal In-Reply-To: References: <4804B03C.6060507@voltaire.com> MIME-Version: 1.0 X-OriginalArrivalTime: 06 May 2008 02:27:53.0258 (UTC) FILETIME=[C962F8A0:01C8AF20] Subject: [Ips] Write residual scenario X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0979135855==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0979135855== Content-Type: multipart/alternative; boundary="_32172296-3411-4292-ac15-550684cfc343_" --_32172296-3411-4292-ac15-550684cfc343_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Dears, In RFC5048 There is a line describing the residual cases: > Note that the Overflow and Underflow scenarios are independent of> Data-In and Data-Out. Either scenario is logically possible in> either direction of data transfer. Can anyone please picture a case for the Data-Out residual? I know it is logically possible, but when it happen it should be a "not good" write response, right? Thank you and Best Regards, Jason HU _________________________________________________________________ 多个邮箱同步管理，live mail客户端万人抢用中 http://get.live.cn/product/mail.html --_32172296-3411-4292-ac15-550684cfc343_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Dears,
 
In RFC5048 There is a line describing the residual cases:
 
> Note that the Overflow and Underflow scenarios are independent of
> Data-In and Data-Out.  Either scenario is logically possible in
> either direction of data transfer.
 
Can anyone please picture a case for the Data-Out residual? I know it is logically possible, but when it happen it should be a "not good" write response, right?
 
Thank you and Best Regards,

Jason HU

用 Windows Live Spaces 展示个性自我，与好友分享生活！ 了解更多信息！ --_32172296-3411-4292-ac15-550684cfc343_-- --===============0979135855== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============0979135855==-- From ips-bounces@ietf.org Thu May 22 22:01:02 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE2A3A6909; Thu, 22 May 2008 22:01:02 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726CB3A6909 for ; Thu, 22 May 2008 22:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rgtljugWYrt for ; Thu, 22 May 2008 22:01:00 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5AC8E3A6863 for ; Thu, 22 May 2008 22:01:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,527,1204531200"; d="gif'147?scan'147,208,217,147";a="49608457" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 22 May 2008 22:01:00 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4N510pA027167 for ; Thu, 22 May 2008 22:01:00 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m4N510mm027986 for ; Fri, 23 May 2008 05:01:00 GMT Received: from xmb-sjc-238.amer.cisco.com ([128.107.186.251]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 May 2008 22:01:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 May 2008 22:01:46 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cisco is looking for Storage protocol developers - 3 positions Thread-Index: Aci8kZ+dL8CYrMa7T8a8YLF088q2igAAHEhA From: "Sadakathullah Mohamed Ali (mohamali)" To: X-OriginalArrivalTime: 23 May 2008 05:01:00.0129 (UTC) FILETIME=[FE35FD10:01C8BC91] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10347; t=1211518860; x=1212382860; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mohamali@cisco.com; z=From:=20=22Sadakathullah=20Mohamed=20Ali=20(mohamali)=22=2 0 |Subject:=20Cisco=20is=20looking=20for=20Storage=20protocol =20developers=20-=203=20positions |Sender:=20; bh=8gU/wy+zVkdh3bbfnX/+oOhozq8S2yjd+HkMFI1Zs/w=; b=kZryjCjB+38z2MOjfZBSG4Cx/UxSRz5JF++DDLp3LWLs3SlpoNrQC/RO3W aEyQJ9f7WxzEYLtrrOg2WIvGyLl61LxQRUM3pFx2S8WpYlclaR4PXWe3i77n 3UxlOQWm8GI96mGGX3em1nYJOB/+krpoN964/TtycZAt4K6tkwO88=; Authentication-Results: sj-dkim-1; header.From=mohamali@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Ips] Cisco is looking for Storage protocol developers - 3 positions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0783862017==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0783862017== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C8BC91.FE243D67" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8BC91.FE243D67 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C8BC91.FE243D67" ------_=_NextPart_002_01C8BC91.FE243D67 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sotrage Guru's =20 Cisco is looking for storage protocol developers with strong "C" coding experience to build the next generation Storage Services for MDS family of SAN switches. =20 If interested please email your resume to mohamali@cisco.com / mohamali AT cisco DOT com =20 Cisco is seeking a Software Engineer to work in a team that builds Storage services for the MDS 9000 family of SAN switches under the data center portfolio. The services include Storage Media Encryption and IP Storage protocols, such as iSCSI and FCIP - primarily targeted to deliver on Cisco's vision of adding innovative services inside the storage area network (SAN) infrastructure. The team is seeking a highly motivated, energetic and focused individual to achieve this. Responsibilities include: - Design and development of embedded software on a multi-core network processor with in-built security and compression engines. - Working with important customers to understand their specific requirements and coming up with creative solutions to address these needs. Being practical and employing appropriate trade-offs between what is desired and what is feasible is key. - Working with QA closely to achieve superior quality software. Qualifications include: - Strong skills in C. - Experience with embedded software development on network processors is highly desirable. - Excellent team player and collaboration skills. - Being practical and employing appropriate trade-offs between what is desired and what is feasible. - Good understanding of networking and Linux OS fundamentals. Knowledge of Fibre channel and SCSI is a strong plus. - MSEE/CS combined with 2-6 years of related experience, or BSEE/CS combined with 4-8+ yrs of related experience. =20 =09 Mohamed Ali Career Services Manager mohamali@cisco.com Mobile :510-402-7625 225 E Tasman Dr San Jose, CA United States www.cisco.com =20 =09 =09 This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.=09 =20 =20 ------_=_NextPart_002_01C8BC91.FE243D67 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sotrage Guru's
 
Cisco = is looking for=20 storage protocol developers with strong "C" coding experience to build = the next=20 generation Storage Services for MDS family of SAN = switches.
 
If = interested please=20 email your resume to mohamali@cisco.com / = mohamali AT cisco=20 DOT com
 
Cisco is seeking a Software Engineer to work in a team that builds = Storage=20 services for the MDS 9000 family of SAN switches under the data center=20 portfolio. The services include Storage Media Encryption and IP Storage=20 protocols, such as iSCSI and FCIP - primarily targeted to deliver on = Cisco's=20 vision of adding innovative services inside the storage area network = (SAN)=20 infrastructure. The team is seeking a highly motivated, energetic and = focused=20 individual to achieve this.

Responsibilities include:
- Design = and=20 development of embedded software on a multi-core network processor with = in-built=20 security and compression engines.
- Working with important customers = to=20 understand their specific requirements and coming up with creative = solutions to=20 address these needs. Being practical and employing appropriate = trade-offs=20 between what is desired and what is feasible is key.
- Working with = QA=20 closely to achieve superior quality software.

Qualifications=20 include:
- Strong skills in C.
- Experience with embedded software = development on network processors is highly desirable.
- Excellent = team=20 player and collaboration skills.
- Being practical and employing = appropriate=20 trade-offs between what is desired and what is feasible.
- Good = understanding=20 of networking and Linux OS fundamentals. Knowledge of Fibre channel and = SCSI is=20 a strong plus.
- MSEE/CS combined with 2-6 years of related = experience, or=20 BSEE/CS combined with 4-8+ yrs of related experience.
 
Mohamed=20 Ali
Career=20 Services Manager

mohamali@cisco.com
Mobile=20 :510-402-7625
225=20 E Tasman Dr
San Jose, CA
United States
www.cisco.com

  
This=20 e-mail may contain confidential and privileged material for = the sole=20 use of the intended recipient. Any review, use, distribution = or=20 disclosure by others is strictly prohibited. If you are not = the=20 intended recipient (or authorized to receive for the = recipient),=20 please contact the sender by reply e-mail and delete all = copies of=20 this message.

 
------_=_NextPart_002_01C8BC91.FE243D67-- ------_=_NextPart_001_01C8BC91.FE243D67 Content-Type: image/gif; name="spacer.gif" Content-Transfer-Encoding: base64 Content-Description: spacer.gif Content-Location: http://www.cisco.com/global/EMEA/brand/signature/default/spacer.gif R0lGODlhCgAKAJEAAAAAAP///////wAAACH5BAEAAAIALAAAAAAKAAoAAAIIlI+py+0PYysAOw== ------_=_NextPart_001_01C8BC91.FE243D67 Content-Type: image/gif; name="footerHead.gif" Content-Transfer-Encoding: base64 Content-Description: footerHead.gif Content-Location: http://www.cisco.com/global/EMEA/brand/signature/default/footerHead.gif R0lGODlhHwIBAJEAAAAAAP///9bY2v///yH5BAEAAAMALAAAAAAfAgEAAAIVlI+py+0Po5y02ouz 3rz7D4biSE4FADs= ------_=_NextPart_001_01C8BC91.FE243D67 Content-Type: image/gif; name="footer.gif" Content-Transfer-Encoding: base64 Content-Description: footer.gif Content-Location: http://www.cisco.com/global/EMEA/brand/signature/default/footer.gif R0lGODlhHwIRAMQAAAAAAP////f3+PX19vHx8u7u7+jp6+Tl59/g4tze4Nvd39ja3NfZ29bY2vHy 8+3u7+vs7eTl5ufp6uTm597g4dze3/j5+fHy8v7+/v39/fv7+/n5+f///wAAAAAAAAAAACH5BAEA ABwALAAAAAAfAhEAAAXY4JIFZGmeaKqubOu+cCzPdG3feK7vfO//wKCwlVkkNsOkcslsOp/QqHRK FW4SE0J1y+16v+CweJwkZCfktHrNbrvf7yymMoDb7/i8fp8fKDABFweAfIWGh4iJijIYBxclBhIa i5SVlpeYXhoSBicQDA+ZoqOkpaYuBQwQKRsIERcCp7KztLV2Ag4RCBYsDgcUDcHCw8TFxsfIycrL zM3Oz9DR0tPU1dbX2Nna29zd3twUEQ625OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wADChxI UEYIADs= ------_=_NextPart_001_01C8BC91.FE243D67-- --===============0783862017== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============0783862017==--