From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752311AbbBWNws (ORCPT <rfc822;w@1wt.eu>);
	Mon, 23 Feb 2015 08:52:48 -0500
Received: from nbfkord-smmo04.seg.att.com ([209.65.160.86]:46404 "EHLO
	nbfkord-smmo04.seg.att.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1752032AbbBWNwr (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 23 Feb 2015 08:52:47 -0500
X-MXL-Hash: 54eb30ae41cc5824-65e722d6405f0630811efb9a620ef0b1d4e389fd
Message-ID: <54EB30A1.9080309@solarflare.com>
Date: Mon, 23 Feb 2015 13:52:33 +0000
From: Edward Cree <ecree@solarflare.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Skidmore, Donald C" <donald.c.skidmore@intel.com>
CC: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>,
        "vyasevic@redhat.com" <vyasevic@redhat.com>,
        "Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
        Alexander Duyck <alexander.duyck@gmail.com>,
        =?UTF-8?B?QmrDuHJuIE1vcms=?= <bjorn@mork.no>,
        "e1000-devel@lists.sourceforge.net" 
	<e1000-devel@lists.sourceforge.net>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "Choi, Sy Jong" <sy.jong.choi@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        David Laight <David.Laight@ACULAB.COM>,
        Hayato Momma <h-momma@ce.jp.nec.com>
Subject: Re: [PATCH v2 2/3] if_link: Add VF multicast promiscuous control
References: <7F861DC0615E0C47A872E6F3C5FCDDBD05E38840@BPXM14GP.gisp.nec.co.jp> <54E73BE4.2040505@solarflare.com> <F6FB0E698C9B3143BDF729DF22286646912AD3E7@ORSMSX110.amr.corp.intel.com>
In-Reply-To: <F6FB0E698C9B3143BDF729DF22286646912AD3E7@ORSMSX110.amr.corp.intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.17.20.45]
X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-21352.005
X-TM-AS-Result: No--2.138400-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
X-AnalysisOut: [v=2.0 cv=VuiU9ZKn c=1 sm=1 a=MkjXnYnS3dyNWGSWLXxFFQ==:17 a]
X-AnalysisOut: [=mypmul4OXYAA:10 a=fVG4DLb5TBsA:10 a=BLceEmwcHowA:10 a=Ikc]
X-AnalysisOut: [TkHD0fZMA:10 a=zRKbQ67AAAAA:8 a=0HtSIViG9nkA:10 a=RrC3GKfT]
X-AnalysisOut: [UDzWPfwn2rgA:9 a=QEXdDO2ut3YA:10]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: <ecree@solarflare.com>
X-SOURCE-IP: [12.187.104.25]
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 20/02/15 21:05, Skidmore, Donald C wrote:
> If a vender specific interface is objectionable maybe a simpler and more generic interface would be for the PF to be able to set a given VF into "trusted" mode... I admit exactly what 'trusted' meant would vary from vender to vender, but it would be a way for the driver to know it could allow configurations such as this.  Just an idea, since we seem to be getting more requests for things such as this.
That's an even worse idea; now you have a generic interface with
completely undefined semantics.
The right way to do this, imho, is to use one of the standard interfaces
for driver-specific gubbins - e.g. sysfs, genetlink or even (whisper it)
ioctls - and put your 'VF promisc mode' setting there.  That way you
have a vendor-specific interface with vendor-specified semantics.
Of those options, I'd recommend sysfs as the best fit.