From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <vincent.jardin@6wind.com>
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com
[209.85.212.171]) by dpdk.org (Postfix) with ESMTP id 64B9AC340
for <dev@dpdk.org>; Tue, 4 Aug 2015 14:51:50 +0200 (CEST)
Received: by wibud3 with SMTP id ud3so22419951wib.0
for <dev@dpdk.org>; Tue, 04 Aug 2015 05:51:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:organization:user-agent
:mime-version:to:cc:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=Uv02UK9SNCQNzSRVwTdk65t6pP91aG+h7Xh0z4EOBTc=;
b=PGye2X83XY811D1OFocLQxQaZM/SEdcqCGwYf04G1e9VvAitYikX0B0WCRXJWVZmym
wwcjRNokTm1DhALZcbekXzNFbojAwAR/rAhjM7ZzsjvMEMEmTX7dM9V1dvpkbO8WVXjx
yy79Gvwbwlfwkm5ivPzW2lC0jwEZdHGi6XAGvNuL+EKycVqACVDeo2WawzeA9WCwEGka
nJFlRNaK4uk8lwD+gLyPjpxSK4Zc+v9R7PkE1oXuyU28SGPueaSmYlH6wqbBv/D7wiUe
stqtV76+2MDm+5NUVCFvLh+0pDXpwzZ3pdjiPHnXc4wnMp+7dmmAXyl4PVUNyvDt/EVN
I5vw==
X-Gm-Message-State: ALoCoQkV3F10ZitMj86xW8byLOCf8YN9FNmqpSLjghMTkdL6W0sQ9Eq3dH883lpTGR6ye7q8/LjU
X-Received: by 10.180.21.244 with SMTP id y20mr7694905wie.65.1438692710187;
Tue, 04 Aug 2015 05:51:50 -0700 (PDT)
Received: from saturne.dev.6wind.com (6wind.net2.nerim.net. [213.41.151.210])
by smtp.gmail.com with ESMTPSA id
k4sm2238944wix.19.2015.08.04.05.51.48
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 04 Aug 2015 05:51:49 -0700 (PDT)
Message-ID: <55C0B564.1090509@6wind.com>
Date: Tue, 04 Aug 2015 14:51:48 +0200
From: Vincent JARDIN <vincent.jardin@6wind.com>
Organization: www.6wind.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Thomas Monjalon <thomas.monjalon@6wind.com>,
"Ouyang, Changchun" <changchun.ouyang@intel.com>
References: <1425602726-26538-1-git-send-email-stephen@networkplumber.org>
<F52918179C57134FAEC9EA62FA2F962511A0C194@shsmsx102.ccr.corp.intel.com>
<20150306082436.43415409@urahara> <205454145.ebl7zG6qks@xps13>
In-Reply-To: <205454145.ebl7zG6qks@xps13>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 2/2] virtio: allow running w/o vlan filtering
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2015 12:51:50 -0000
Thomas, Changchun,
On 29/07/2015 14:56, Thomas Monjalon wrote:
> Back on this old patch, it seems justified but nobody agreed.
>
> --- a/lib/librte_pmd_virtio/virtio_ethdev.c
> +++ b/lib/librte_pmd_virtio/virtio_ethdev.c
> @@ -1288,7 +1288,6 @@ virtio_dev_configure(struct rte_eth_dev *dev)
> && !vtpci_with_feature(hw, VIRTIO_NET_F_CTRL_VLAN)) {
> PMD_DRV_LOG(NOTICE,
> "vlan filtering not available on this host");
> - return -ENOTSUP;
> }
>
> 2015-03-06 08:24, Stephen Hemminger:
>> "Ouyang, Changchun" <changchun.ouyang@intel.com> wrote:
>>>> From: Stephen Hemminger
>>>> Vlan filtering is an option, and not a requirement.
>>>> If host does not support filtering then it can be done in software.
+1 with Stephen, remove return -ENOTSUP;
applications must not fail, software stacks will handle it. We did
experiment some issues when testpmd was failing while it was supposed to
run. A notice would be good enough.
>>>
>>> The question is that guest only send command, no real action to do the vlan filter.
>>> So if both host and guest have no real action for vlan filter, who will do it?
>>
>> The virtio driver has features.
>> Guest can not send commands to host where feature bit not enabled.
>> Application can call filter_set and check if filter worked or not.
>>
>> Our code already had to do MAC and VLAN validation of incoming packets
>> therefore if hardware can't do vlan match, there is no problem.
>> I would expect other applications would do the same thing.
>>
>> Failing during configuration is bad. DPDK API should never force
>> application to play "guess the working configuration" with the device
>> driver or do string match on "which device is this anyway"
Agree, it is not a failure of a configuration, it is a failure of
negotiation of virtio's capabilities.
Let's use another example: we do not expect a guest kernel to panic()
because it is not properly negotiated? So why should a DPDK application
fail and return -ENOTSUP?
Thank you,
Vincent