From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id 8C8762949 for ; Fri, 4 Mar 2016 14:40:25 +0100 (CET) Received: by mail-wm0-f51.google.com with SMTP id l68so20816671wml.0 for ; Fri, 04 Mar 2016 05:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Uv0VHoH2SbF9GBG3GhDqRGcK3iJ9a1A/vgdRnUG5fvI=; b=AdmNnZMOaQOLd7aYNROiyJs6TmLfzVNFrJL98P6ROmxSoLhq9EbJyqDNAts/wFDXZa pOt616sYml91pDidDsouk6XXNKsRG5lYcyIw6L+leGBc5ChVgY8KoWBlz6qFe4cpqKsL XGB39zqnhxJLP7PP2n7DS33PIqdzCxCVd793Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Uv0VHoH2SbF9GBG3GhDqRGcK3iJ9a1A/vgdRnUG5fvI=; b=ee8o7hKzNzciohXxYq4OneA82gxiTkrpbkPrLAJAUS8rG0Tq9b0mb2TmosHbtopWCn vwS64ARi9Wz3Vxspf5QWD32vbrVRMaiuV6FvGCWUI+YO9seimMTYnM6KxGn0f0HMBZBk ZPjg+ikxJbWZfpx2lNKY+qo4yNPbV47Y5gtVnGK5gJerPv/PRT3MMfMo+nY1PZwOaZay xeD6frHgo2RobXnqKjJgYEnIprfIWww2chahGHLpgfMcyUr01WWOQCWOJ+hWivBRl2z7 Y3vbkcq2+vrOWqz4QQLEnSm472xm6TM6wBvLcYmmt5zgpHv456OG8cOLByf3cs9n+n8A zLRQ== X-Gm-Message-State: AD7BkJK2aur0YSd04t6Fuj7N05CXXvJ0wRIDJylbInVStRN43yPNSJEI2HCxlqZQJeks5EfK X-Received: by 10.194.158.36 with SMTP id wr4mr8731760wjb.134.1457098825334; Fri, 04 Mar 2016 05:40:25 -0800 (PST) Received: from [172.18.45.59] ([195.11.233.227]) by smtp.googlemail.com with ESMTPSA id u16sm3448158wmd.5.2016.03.04.05.40.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Mar 2016 05:40:24 -0800 (PST) To: "Ananyev, Konstantin" , Olivier MATZ , "dev@dpdk.org" References: <56D5CE1B.2070002@linaro.org> <56D95547.8080601@6wind.com> <2601191342CEEE43887BDE71AB97725836B162E0@irsmsx105.ger.corp.intel.com> From: Zoltan Kiss Message-ID: <56D99049.5090102@linaro.org> Date: Fri, 4 Mar 2016 13:40:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB97725836B162E0@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] rte_mbuf's packet_type field 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: Fri, 04 Mar 2016 13:40:25 -0000 On 04/03/16 10:58, Ananyev, Konstantin wrote: > Hi, > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier MATZ >> Sent: Friday, March 04, 2016 9:29 AM >> To: Zoltan Kiss; dev@dpdk.org >> Subject: Re: [dpdk-dev] rte_mbuf's packet_type field >> >> Hi Zoltan, >> >> On 03/01/2016 06:15 PM, Zoltan Kiss wrote: >>> I have a quick question about this field: how do I know if the >>> underlying PMD supports a particular protocol parsing. Let's say I want >>> to check for SCTP packets, looking at this field tells me EITHER the >>> packet is SCTP (or not), OR that the hardware has no idea about SCTP. Is >>> there a way to figure that support out? >> >> I'm not aware of such a feature. I guess you want to avoid to re-check >> all protocols in software if the hardware supports some of them and >> did not recognize them? In that case it may be interesting, but it would >> result in a lot of feature flags. > > Nothing in the mainline, but there is a patches in-flight: > http://dpdk.org/dev/patchwork/patch/10921/ Thanks, this would do it! Regards, Zoltan > > Konstantin > >> >> Regards, >> Olivier >