From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by dpdk.org (Postfix) with ESMTP id 7437AB36F for ; Mon, 11 Aug 2014 13:58:27 +0200 (CEST) Received: by mail-lb0-f171.google.com with SMTP id l4so5827673lbv.16 for ; Mon, 11 Aug 2014 05:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=GsmbDUDvE4dIWEYnnITQ+/WNarrXtO4maJKCSDQwsoQ=; b=E/mvqTI+v99T36BwOB1L8EXGzLqWVYNogKEpLg0tuUNd0yz4LJC5AdPcpLLIKrVYHm rGwN867GB886SIkO8nHqKvN6jeMgNHf5bpRJqgE54XMBopfSVZJrxThPnQEdAi5bZR8U Pgt6JflfRrWBKva2fGGGH6a02RZjW7wNZU18kpGERrbK/7yEX6nr3psYCwbIf4riJBU4 85uI/f2zl/useLYQdXAkTkl9pF2UVctNf2gvqpOfpqR//VJF9aXXoMgmeuFg6suK6df5 x1meicy/udY9gnZ1tQIeVn9Nrfa20pam6OZgslkYCcA/Ln6sbTyfhR1hQi5xz8qmRkfo XcGQ== X-Received: by 10.152.88.39 with SMTP id bd7mr2127721lab.89.1407758477638; Mon, 11 Aug 2014 05:01:17 -0700 (PDT) Received: from [192.168.15.101] ([91.224.132.27]) by mx.google.com with ESMTPSA id xo1sm17999257lbb.16.2014.08.11.05.01.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 05:01:17 -0700 (PDT) Message-ID: <53E8B08B.5000406@gmail.com> Date: Mon, 11 Aug 2014 16:01:15 +0400 From: Dmitry Vyal User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dev@dpdk.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dpdk-dev] SFP/SFP+ modules hotplugging question. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 11:58:27 -0000 Dear mailing list, I have a question concerning SFP modules hotplugging. I made some experiments and want to confirm my findings. Looks like hotplug is basically supported out of the box, the only thing one has to do is to register callbacks for RTE_ETH_EVENT_INTR_LSC and avoid sending mbufs to NIC when link is down. Implemented that, I can now remove an SFP module in the middle on a run and insert another one and NIC operation resumes. So far so good. But then I inserted an SFP module into SFP+ slot during the testing I got an unsatisfactory behavior. Link went down but to my surprise it didn't go up after I replaced SFP module with one of SFP+ type. I had to restart the application to bring port back into the working state. So my question is whether it's possible to detect and gracefully overcome such situations without disrupting other ports operation? P.S. Forgot to mention, I observed this behavior with DPDK-1.5.1 and 82599EB NIC. Best regards, Dmitry.