From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id D4B7E1E517 for ; Tue, 12 Jun 2018 16:18:36 +0200 (CEST) Received: by mail-wm0-f67.google.com with SMTP id n5-v6so23656280wmc.5 for ; Tue, 12 Jun 2018 07:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=O9lOwvheNDJHvBkSG9igE4YOAEfCniylSoWps+gGfIY=; b=wmRx05CuHelnhyrSaMyi86won6rYHz/eaJIpxuT58snihv1WfjWxyEWxf3Cwwb2Ax7 rU0xOgEIsmI2ftJupDmlvRAAS7REnD/9q4xtuUl080xt0+CCsoIunPamjp8nbfPYbZ9T FouZAEzkPZg6f1RbUwhyhN+nWZZfU16X8d47T4u8F68yBcbGXZzovZpkUGETc6j6SEuq aS6tiDuaO9rciKxUEgQ6SHcxGkw7jVzCI5UgSBBrt4j6Slq1Yw7q8Q538mFo0lMaBT+q ZJ66qq61EaseLajVuqi7vIn8m4gHsjqsLfM7XRkIQ55Kq7aRgi7V7dzWzB2Hyj5F5Fbo v3uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=O9lOwvheNDJHvBkSG9igE4YOAEfCniylSoWps+gGfIY=; b=hTxj+/RS/GYEwD9F7Yoyc0+NwP9jIOLfF2bVnb1qy/sXYlk7q83Uq9T+vAZqD1x1oU xs95Ej81DSdyodbyOQS91ms5exUbhhGeljeM3GDYxyoMEGtIomcmNGB+98RQL+lwci+y vDat6JzlwCFggFmPWzo0+F2Ysj40EIhkAvIrfvQS9dcTkB2M8lms1/p472KkaiDu4vOY PRNXrwiGq5L+LA34SVeGC4VxZMy6HqD2C7D7x/9ql1W4m3Cq3ecd/VTavZaLKFnkorvz Rr/FKff6M8R5LkLAyZX3V5807w6HOk7B7+8LIyk5JYe0rgii3rgVjfV+LMLlcDrSxk2b VKxQ== X-Gm-Message-State: APt69E2oD0GwuYUrSgE6FDT2mR9Tda45QvT9KfmT/IZBoHotgccVcrtU 1/WEVuz6VuESc2C4xLAS2FSWyQ== X-Google-Smtp-Source: ADUXVKLK+kWdC3qwPixGFd7o5VHeuh9u6zkkPKua0ykVigBJPiS+Gjbhreg/KaXEqZji3ZRBQ50rpA== X-Received: by 2002:a1c:387:: with SMTP id 129-v6mr401316wmd.53.1528813116519; Tue, 12 Jun 2018 07:18:36 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id e63-v6sm793348wma.46.2018.06.12.07.18.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jun 2018 07:18:35 -0700 (PDT) Date: Tue, 12 Jun 2018 16:18:20 +0200 From: Adrien Mazarguil To: "Xueming(Steven) Li" Cc: Shahaf Shuler , "dev@dpdk.org" Message-ID: <20180612141820.GA4025@6wind.com> References: <20180612132022.GX4025@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [dpdk-dev, 5/7] net/mlx5: add port representor awareness 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: , X-List-Received-Date: Tue, 12 Jun 2018 14:18:37 -0000 On Tue, Jun 12, 2018 at 01:57:45PM +0000, Xueming(Steven) Li wrote: > > -----Original Message----- > > From: Adrien Mazarguil > > Sent: Tuesday, June 12, 2018 9:20 PM > > To: Xueming(Steven) Li > > Cc: Shahaf Shuler ; dev@dpdk.org > > Subject: Re: [dpdk-dev,5/7] net/mlx5: add port representor awareness > > > > On Mon, Jun 11, 2018 at 01:05:55PM +0000, Xueming(Steven) Li wrote: > > > Hi Adrien, > > > > > > Couldn't find your original email from inbox anyway, have to start a new thread here. > > > > > > +static int > > > > +mlx5_cmp_ibv_name(const void *a, const void *b) { > > > > + const char *name_a = (*(const struct ibv_device *const *)a)->name; > > > > + const char *name_b = (*(const struct ibv_device *const *)b)->name; > > > > + size_t i = 0; > > > > + > > > > + while (name_a[i] && name_a[i] == name_b[i]) > > > > + ++i; > > > > + return atoi(name_a + i) - atoi(name_b + i); > > > > > > Comparing "1" and "10" here will return 0, does this matter? > > > > Sure it does! The whole point of this function is precisely to avoid this kind of issues. I'll fix it > > for v2, thanks. > > > > > > > > + if (n > 1) { > > > > + /* > > > > + * The existence of several matching entries means port > > > > + * representors have been instantiated. No existing Verbs > > > > + * call nor /sys entries can tell them apart at this point. > > > > + * > > > > + * While definitely hackish, assume their names are numbered > > > > + * based on order of creation with master device first, > > > > + * followed by first port representor, followed by the > > > > + * second one and so on. > > > > + */ > > > > + DRV_LOG(WARNING, > > > > + "probing device with port representors involves" > > > > + " heuristics with uncertain outcome"); > > > > + qsort(ibv_match, n, sizeof(*ibv_match), mlx5_cmp_ibv_name); > > > > + DRV_LOG(WARNING, "assuming \"%s\" is the master device", > > > > + ibv_match[0]->name); > > > > + for (ret = 1; ret < n; ++ret) > > > > + DRV_LOG(WARNING, > > > > + "assuming \"%s\" is port representor #%d", > > > > + ibv_match[ret]->name, ret - 1); > > > > > > Such dump will appear when attaching each rep port, how about just do > > > it for PF in DEBUG level? > > > > It occurs only once when probing the master device and detecting the presence of representors, not for > > each of them. > > > > I prefer to leave it as a warning because this detection approach, while an undeniable improvement > > over not checking anything and ending up configuring the wrong netdevice, is unfortunately not 100% > > accurate. This will be improved, however users must be warned of possible issues in the meantime. > > Yes, the list is different when VF number changed outside, a full dump should be helpful, how about set it to DEBUG or INFO level? > Users don't need to know this, just for debug purpose. Because by "assuming" things, there's a slight possibility for the PMD to be wrong. It's not a mere debug message. Using the wrong IB device may silently wreak havoc on some systems, therefore since the PMD can't be sure, users are warned about this fact and what IB devices will be used. This calls for extra attention and manual checks (where possible) *before* an issue is encountered, until we replace this piece of code with a safer approach. I think a WARNING level is warranted. -- Adrien Mazarguil 6WIND