From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24DECC433E7 for ; Tue, 13 Oct 2020 14:37:31 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 672092482B for ; Tue, 13 Oct 2020 14:37:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 672092482B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8B9C41DBC9; Tue, 13 Oct 2020 16:37:28 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 9949F1D9DE for ; Tue, 13 Oct 2020 06:31:48 +0200 (CEST) IronPort-SDR: 89iZZEzncuV14K+P1VlFqH0I/9ekrB/e4KWRWmbl0qhzJqCaSYbGVei+SwS7AOn3x1xUvFq0TZ 1dTqk4TdBD9A== X-IronPort-AV: E=McAfee;i="6000,8403,9772"; a="163209979" X-IronPort-AV: E=Sophos;i="5.77,369,1596524400"; d="scan'208";a="163209979" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2020 21:31:46 -0700 IronPort-SDR: FFy36MZDALJBYxOlk4ZTlH5fPgX7L/px2bcRqXrNKFSrm66vSt/AWJueegD+3ZxTgVNZYRUJLt L2VzWFXiaBsQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,369,1596524400"; d="scan'208";a="318164901" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by orsmga006.jf.intel.com with ESMTP; 12 Oct 2020 21:31:46 -0700 Received: from orsmsx608.amr.corp.intel.com (10.22.229.21) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 12 Oct 2020 21:31:45 -0700 Received: from orsmsx608.amr.corp.intel.com (10.22.229.21) by ORSMSX608.amr.corp.intel.com (10.22.229.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 12 Oct 2020 21:31:45 -0700 Received: from orsmsx608.amr.corp.intel.com ([10.22.229.21]) by ORSMSX608.amr.corp.intel.com ([10.22.229.21]) with mapi id 15.01.1713.004; Mon, 12 Oct 2020 21:31:45 -0700 From: "Niu, Yawei" To: =?utf-8?B?R2HDq3RhbiBSaXZldA==?= CC: "dev@dpdk.org" , "spdk@lists.01.org" , "Harris, James R" , "Vanda, Sydney M" Thread-Topic: [dpdk-dev] FW: [SPDK] Re: Potential defect in pci_unplug() Thread-Index: AQHWla4qk5BGG1Cq2kO5tYgu9t1ouKl/zEIAgBArAICABgxagA== Date: Tue, 13 Oct 2020 04:31:45 +0000 Message-ID: <378B66E2-6A70-446B-9AC4-622B165C45DB@intel.com> References: <748FDEF7-6BB0-4D27-B630-4C991D06B6F8@intel.com> <98D9624D-F475-425B-9B06-F13CD9C4884C@intel.com> <20201009160959.dmqhwtqktbyagxbk@u256.net> In-Reply-To: <20201009160959.dmqhwtqktbyagxbk@u256.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="utf-8" Content-ID: <035E82EDE164BA4CACF47CB91DE6FE72@intel.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 13 Oct 2020 16:37:27 +0200 Subject: Re: [dpdk-dev] FW: [SPDK] Re: Potential defect in pci_unplug() X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" VGhhbmtzIGEgbG90IGZvciB0aGUgcmVwbHksIEdhZXRhbiENCg0KU28gc2VlbXMgd2UgaGF2ZSB0 byBleHBsaWNpdGx5IHVzZSBmYWlsc2FmZSBQTUQgdG8gZGVhbCB3aXRoIHRoaXMgcmUtcGx1ZyBj YXNlPyBJJ20gbm90IHF1aXRlIHN1cmUgaWYgdGhhdCdsbCBjb29wZXJhdGUgd2l0aCBjdXJyZW50 IFNQREsgaG90cGx1ZyBjb2RlIHNlYW1sZXNzbHkuDQoNCkkgdGhpbmsgaXQgd291bGQgYmUgZ3Jl YXQgaWYgU1BESy9EUERLIGNhbiBmaXggaXQgaW50ZXJuYWxseSAocmVjb25zdHJ1Y3QgdGhlIGRl dmFyZ3Mgb24gcmUtcGx1ZyBzb21laG93PykgYW5kIHByb3ZpZGUgYSB0cmFuc3BhcmVudCBob3Rw bHVnIGNhcGFiaWxpdHkgdG8gYXBwcy4NCg0KVGhhbmtzDQotTml1DQoNCu+7v09uIDIwMjAvMTAv MTAsIDEyOjEwIEFNLCAiR2HDq3RhbiBSaXZldCIgPGdyaXZlQHUyNTYubmV0PiB3cm90ZToNCg0K ICAgIEhlbGxvLA0KICAgIA0KICAgIE9uIDI5LzA5LzIwIDAxOjE1ICswMDAwLCBOaXUsIFlhd2Vp IHdyb3RlOg0KICAgID4gDQogICAgPiANCiAgICA+IE9uIDIwMjAvOS8yOCwgMTE6NDQgUE0sICJI YXJyaXMsIEphbWVzIFIiIDxqYW1lcy5yLmhhcnJpc0BpbnRlbC5jb20+IHdyb3RlOg0KICAgID4g DQogICAgPiAgICAgSGkgTml1LA0KICAgID4gICAgIA0KICAgID4gICAgIEkgYWdyZWUsIHRoaXMg ZG9lc24ndCBsb29rIHJpZ2h0LiAgQ291bGQgeW91IGZpbGUgYW4gU1BESyBpc3N1ZSBmb3IgdGhp cyB0byBtYWtlIHN1cmUgd2UgdHJhY2sgaXQ/ICBBbmQgdGhlbiB0cnkgc2VuZGluZyBhbiBlLW1h aWwgdG8gdGhlIERQREsgbWFpbGluZyBsaXN0PyAgSSdtIG9wZW4gdG8gc3VibWl0dGluZyBhIHBh dGNoIHRvIG91ciBEUERLIHN1Ym1vZHVsZSBzaG9ydC10ZXJtLCBidXQgb25seSBpZiB3ZSBnZXQg YWdyZWVtZW50IHdpdGggRFBESyBjb21tdW5pdHkgdGhhdCB0aGlzIGZpeCBpcyBjb3JyZWN0Lg0K ICAgID4gICAgIA0KICAgID4gICAgIFRoYW5rcywNCiAgICA+ICAgICANCiAgICA+ICAgICBKaW0N CiAgICA+ICAgICANCiAgICA+ICAgICANCiAgICA+ICAgICBPbiA5LzI4LzIwLCAxMjoxNyBBTSwg Ik5pdSwgWWF3ZWkiIDx5YXdlaS5uaXVAaW50ZWwuY29tPiB3cm90ZToNCiAgICA+ICAgICANCiAg ICA+ICAgICAgICAgSGksDQogICAgPiAgICAgDQogICAgPiAgICAgICAgIEluIHRoZSBwY2lfdW5w bHVnKCkgKGRwZGsvZHJpdmVycy9idXMvcGNpL3BjaV9jb21tb24uYyksIHdoeSBkbyB3ZSBjYWxs IHJ0ZV9kZXZhcmdzX3JlbW92ZSgpIHRvIHJlbW92ZSB0aGUgc2F2ZWQgZGV2aWNlIGFyZ3M/IFRo YXQgbG9va3MgYSBkZWZlY3QgdG8gbWUsIHNpbmNlIHRoYXTigJlsbCByZXN1bHQgaW4gdGhlIGhv dCByZW1vdmVkIGRldmljZSBmYWlsZWQgdG8gYmUgZGV0ZWN0ZWQgd2hlbiBpdOKAmXMgcGx1Z2dl ZCBiYWNrICh3aGVuIHdoaXRlIGxpc3Qgb3B0aW9uIHdhcyBwcm92aWRlZCksIHRoZSBzaXR1YXRp b24gaXMgZGVzY3JpYmVkIGZvbGxvd2luZzoNCiAgICA+ICAgICANCiAgICA+ICAgICAgICAgICAx LiAgQXBwIHN0YXJ0cyB3aXRoIHdoaXRlIGxpc3Qgb3B0aW9uIHByb3ZpZGVkLCBsZXTigJlzIHN1 cHBvc2UgdGhlIGRldmljZSBpbiB3aGl0ZSBsaXN0IGlzOiAwMDAwOjgxOjAwLjA7DQogICAgPiAg ICAgICAgICAgMi4gIHJ0ZV9kZXZhcmdzX2FkZCgpIGlzIGNhbGxlZCB0byBhZGQgdGhpcyBkZXZp Y2UgYXJnIG9uIHJ0ZV9lYWxfaW5pdCgpOw0KICAgID4gICAgICAgICAgIDMuICBJc3N1ZSDigJxl Y2hvIDEgPiAvc3lzL2J1cy9wY2kvZGV2aWNlcy8wMDAwXDo4MVw6MDAuMC9yZW1vdmXigJ0gdG8g aG90IHJlbW92ZSB0aGUgZGV2aWNlOw0KICAgID4gICAgICAgICAgIDQuICBwY2lfdW5wbHVnKCkg aXMgY2FsbGVkIHRvIHJlbW92ZSB0aGUgZGV2aWNlLCBhbmQgcnRlX2RldmFyZ3NfcmVtb3ZlKCkg aXMgY2FsbGVkLCBzbyB0aGlzIGRldmljZSBhcmcgZm9yIHdoaXRlIGxpc3QgaXMgcmVtb3ZlIHRv bzsNCiAgICA+ICAgICAgICAgICA1LiAgSXNzdWUg4oCcZWNobyAxID4gL3N5cy9idXMvcGNpL3Jl c2NhbuKAnSB0aGVuIOKAnFBDSV9XSElURUxJU1Q94oCdMDAwMDo4MTowMC4w4oCdIHNwZGsvc2Ny aXB0L3NldHVwLnNo4oCdIHRvIGRvIGhvdCBwbHVnOw0KICAgID4gICAgICAgICAgIDYuICBJbiBw Y2lfc2Nhbl9vbmUoKSwgbmV3IGRldiBpcyBnZW5lcmF0ZWQsIGhvd2V2ZXIsIHRoZSBkZXYtPmRl dmljZS5kZXZhcmdzIGlzIHNldCBOVUxMIHNpbmNlIHRoZSBkZXZpY2UgYXJncyBoYXMgYmVlbiBy ZW1vdmVkIG9uIGRldmljZSB1bnBsdWc7DQogICAgPiAgICAgICAgICAgNy4gIHJ0ZV9wY2lfcHJv YmUoKSBkb2VzIHdoaXRlIGxpc3Qgc2NhbiwgaG93ZXZlciwgaXQgdW5leHBlY3RlZGx5IHNraXBz IHRoZSBkZXZpY2UgYmVjYXVzZSB0aGUgZGV2YXJncyBvZiB0aGUgZGV2aWNlIGlzIE5VTEwgbm93 Ow0KICAgID4gICAgIA0KICAgID4gICAgICAgICBJIGRvbuKAmXQgZnVsbHkgdW5kZXJzdGFuZCB0 aGUgRFBESyBjb2RlLCBidXQgdGhpcyBydGVfZGV2YXJnc19yZW1vdmUoKSBpbiBwY2lfdW5wbHVn KCkgZG9lc27igJl0IG1ha2Ugc2Vuc2UgdG8gbWUgKHdoZW4gSSBjb21tZW50ZWQgaXQgb3V0LCBz ZWVtcyBldmVyeXRoaW5nIHdpbGwgd29yayBhcyBleHBlY3RlZCkuIElzIHRoaXMgYSBnbGl0Y2gg b3IgSSBtaXNzZWQgYW55dGhpbmc/DQogICAgDQogICAgVGhpcyBpcyBub3QgYSBnbGl0Y2gsIHRo ZSBiZWhhdmlvciBpcyBpbnRlbmRlZC4NCiAgICBXaGVuIGEgZGV2aWNlIGlzIHVucGx1Z2dlZCBm cm9tIHRoZSBzeXN0ZW0sIHRoZXJlIGlzIG5vIGV4cGVjdGF0aW9uIHRoYXQNCiAgICBpdCB3aWxs IHJlYXBwZWFyIGF0IHRoZSBzYW1lIFBDSSBhZGRyZXNzLg0KICAgIA0KICAgIFdoZW4gYW4gYXBw bGljYXRpb24gcmVjZWl2ZXMgdGhlIFJNViBldmVudCBmb3IgdGhlIGRldmljZSwgaXQgaXMgYWxl cnRlZA0KICAgIHRoYXQgdGhlIGRldmljZSB3YXMgcmVtb3ZlZC4gSXQgaXMgaXRzIHJlc3BvbnNp YmlsaXR5IHRoZW4gdG8gZGV0ZWN0DQogICAgd2hlbiBhIGRldmljZSBpdCB3YW50cyB0byB1c2Ug aXMgYWRkZWQgYmFjay4gSXQgY2FuIGRvIHNvIHZpYSB1ZGV2IG9uDQogICAgbGludXggZm9yIGV4 YW1wbGUsIGJ1dCBpdCBpcyB0aWdodGx5IGNvdXBsZWQgd2l0aCB0aGUgb3BlcmF0aW5nIHN5c3Rl bQ0KICAgIG9yIGV2ZW4gdGhlIGRpc3RyaWJ1dGlvbi4gQlNEIGFuZCB3aW5kb3dzIHdvbid0IHdv cmsgdGhhdCB3YXkuDQogICAgDQogICAgVGhpcyBpcyB0aGUgcmVhc29uIHRoaXMgcmVzcG9uc2li aWxpdHkgd2FzIGxlZnQgdG8gdGhlIGFwcGxpY2F0aW9uLg0KICAgIA0KICAgIFRoZSBmYWlsc2Fm ZSBQTUQgYXR0ZW1wdHMgdG8gb2ZmZXIgdHJhbnNwYXJlbnQgaG90cGx1ZyBjYXBhYmlsaXR5IHRv DQogICAgZXhpc3RpbmcgYXBwbGljYXRpb25zLiBJdCBoYWQgdG8gZGVhbCB3aXRoIHRoaXMgZXhh Y3QgaXNzdWUuIFRoZSBzb2x1dGlvbg0KICAgIHVzZWQgdGhlcmUgaGFzIGJlZW4gdG8gdXNlIGVp dGhlcjoNCiAgICANCiAgICAgICogdGhlIGV4ZWMoKSBzdWItZGV2aWNlIHR5cGUsIHRoYXQgdGFr ZXMgYSBzaGVsbCBjb21tYW5kIGFzDQogICAgICAgIHBhcmFtZXRlciwgd2hpY2ggc2hvdWxkIHJl dHVybiBhIHZhbGlkIGRldmljZSBhZnRlciBzdWNjZXNzZnVsDQogICAgICAgIGV4ZWN1dGlvbi4g SW50ZW50aW9uIGlzIGZvciB0aGUgdXNlciB0byBkZWNsYXJlIGEgc2NyaXB0IHRoYXQgd2lsbA0K ICAgICAgICBkZXRlY3QgZGV2aWNlIGhvdHBsdWcgb24gdGhlIHN5c3RlbSB1c2luZyBvdGhlciBt YXRjaGVzIHRoYW4gUENJDQogICAgICAgIGFkZHJlc3MgKGFzIGl0IGlzIHVucmVsaWFibGUpLCBz dWNoIGFzIE1BQyBhZGRyZXNzLg0KICAgIA0KICAgICAgKiB0aGUgZmQoKSBzdWItZGV2aWNlIHR5 cGUsIHdoaWNoIGlzIGEgcGlwZSB3aGVyZSBhbm90aGVyIHBpZWNlIG9mIGNvZGUNCiAgICAgICAg d2lsbCBzZW5kIGRldmljZSBJRCBpbnRvLiBUaGlzIGlzIHdoYXQgdmRldl9uZXR2c2MgZG9lcyBj dXJyZW50bHk6DQogICAgICAgIGl0IGRldGVjdHMgb24gaXRzIG93biB2YWxpZCBOZXRWU0MgZGV2 aWNlcyBhbmQgd2hlbiBvbmUgaXMgc3VpdGFibGUsDQogICAgICAgIGl0IHNlbmRzIGl0cyBQQ0kg aWQgaW4gdGhpcyBwaXBlIHRvIGZhaWxzYWZlIGRyaXZlci4NCiAgICANCiAgICBTZWUgaHR0cHM6 Ly9kb2MuZHBkay5vcmcvZ3VpZGVzL25pY3MvZmFpbF9zYWZlLmh0bWwNCiAgICAgICAgc2VjdGlv biA1NS4zLjEuIEZhaWwtc2FmZSBjb21tYW5kIGxpbmUgcGFyYW1ldGVycyBmb3IgZG9jdW1lbnRh dGlvbi4NCiAgICANCiAgICBXaGVuIGEgbmV3IGRldmljZSBpcyBob3RwbHVnZ2VkIGludG8gRFBE SywgaXQgaXMgZGVzY3JpYmVkIGJ5IGFuDQogICAgcnRlX2RldmFyZ3MuIFRoaXMgbmV3IGRldmFy Z3MgaXMgdGhlIG9uZSB0aGF0IHdpbGwgYmUgdXNlZCBmb3INCiAgICBpZGVudGlmaWNhdGlvbiBk dXJpbmcgc2NhbiBhbmQgcHJvYmUuIEFzIGl0IHJlcGxhY2VzIHRoZSBvbGQsIHRoZSBvbGQNCiAg ICBvbmUgbmVlZHMgdG8gYmUgcmVtb3ZlZCBhcyBpdCBpcyBzdGFsZS4NCiAgICANCiAgICBSZWdh cmRzLA0KICAgIC0tIA0KICAgIEdhw6t0YW4NCiAgICANCg0K From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============8947422864966042508==" MIME-Version: 1.0 From: Niu, Yawei Subject: [SPDK] Re: [dpdk-dev] FW: Re: Potential defect in pci_unplug() Date: Tue, 13 Oct 2020 04:31:45 +0000 Message-ID: <378B66E2-6A70-446B-9AC4-622B165C45DB@intel.com> In-Reply-To: 20201009160959.dmqhwtqktbyagxbk@u256.net List-ID: To: spdk@lists.01.org --===============8947422864966042508== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Thanks a lot for the reply, Gaetan! So seems we have to explicitly use failsafe PMD to deal with this re-plug c= ase? I'm not quite sure if that'll cooperate with current SPDK hotplug code= seamlessly. I think it would be great if SPDK/DPDK can fix it internally (reconstruct t= he devargs on re-plug somehow?) and provide a transparent hotplug capabilit= y to apps. Thanks -Niu =EF=BB=BFOn 2020/10/10, 12:10 AM, "Ga=C3=ABtan Rivet" wr= ote: Hello, = On 29/09/20 01:15 +0000, Niu, Yawei wrote: > = > = > On 2020/9/28, 11:44 PM, "Harris, James R" wrote: > = > Hi Niu, > = > I agree, this doesn't look right. Could you file an SPDK issue f= or this to make sure we track it? And then try sending an e-mail to the DP= DK mailing list? I'm open to submitting a patch to our DPDK submodule shor= t-term, but only if we get agreement with DPDK community that this fix is c= orrect. > = > Thanks, > = > Jim > = > = > On 9/28/20, 12:17 AM, "Niu, Yawei" wrote: > = > Hi, > = > In the pci_unplug() (dpdk/drivers/bus/pci/pci_common.c), why = do we call rte_devargs_remove() to remove the saved device args? That looks= a defect to me, since that=E2=80=99ll result in the hot removed device fai= led to be detected when it=E2=80=99s plugged back (when white list option w= as provided), the situation is described following: > = > 1. App starts with white list option provided, let=E2=80= =99s suppose the device in white list is: 0000:81:00.0; > 2. rte_devargs_add() is called to add this device arg on r= te_eal_init(); > 3. Issue =E2=80=9Cecho 1 > /sys/bus/pci/devices/0000\:81\:= 00.0/remove=E2=80=9D to hot remove the device; > 4. pci_unplug() is called to remove the device, and rte_de= vargs_remove() is called, so this device arg for white list is remove too; > 5. Issue =E2=80=9Cecho 1 > /sys/bus/pci/rescan=E2=80=9D th= en =E2=80=9CPCI_WHITELIST=3D=E2=80=9D0000:81:00.0=E2=80=9D spdk/script/setu= p.sh=E2=80=9D to do hot plug; > 6. In pci_scan_one(), new dev is generated, however, the d= ev->device.devargs is set NULL since the device args has been removed on de= vice unplug; > 7. rte_pci_probe() does white list scan, however, it unexp= ectedly skips the device because the devargs of the device is NULL now; > = > I don=E2=80=99t fully understand the DPDK code, but this rte_= devargs_remove() in pci_unplug() doesn=E2=80=99t make sense to me (when I c= ommented it out, seems everything will work as expected). Is this a glitch = or I missed anything? = This is not a glitch, the behavior is intended. When a device is unplugged from the system, there is no expectation that it will reappear at the same PCI address. = When an application receives the RMV event for the device, it is alerted that the device was removed. It is its responsibility then to detect when a device it wants to use is added back. It can do so via udev on linux for example, but it is tightly coupled with the operating system or even the distribution. BSD and windows won't work that way. = This is the reason this responsibility was left to the application. = The failsafe PMD attempts to offer transparent hotplug capability to existing applications. It had to deal with this exact issue. The soluti= on used there has been to use either: = * the exec() sub-device type, that takes a shell command as parameter, which should return a valid device after successful execution. Intention is for the user to declare a script that will detect device hotplug on the system using other matches than PCI address (as it is unreliable), such as MAC address. = * the fd() sub-device type, which is a pipe where another piece of co= de will send device ID into. This is what vdev_netvsc does currently: it detects on its own valid NetVSC devices and when one is suitable, it sends its PCI id in this pipe to failsafe driver. = See https://doc.dpdk.org/guides/nics/fail_safe.html section 55.3.1. Fail-safe command line parameters for documentation. = When a new device is hotplugged into DPDK, it is described by an rte_devargs. This new devargs is the one that will be used for identification during scan and probe. As it replaces the old, the old one needs to be removed as it is stale. = Regards, -- = Ga=C3=ABtan = --===============8947422864966042508==--