From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 2AF8F9591 for ; Wed, 6 Jan 2016 11:01:12 +0100 (CET) Received: by mail-wm0-f47.google.com with SMTP id f206so53480304wmf.0 for ; Wed, 06 Jan 2016 02:01:12 -0800 (PST) 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:mail-followup-to:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to; bh=aA5+QYWADnxObKJFy0L/8mVyN86fXPg4DK+5/MNYQGk=; b=gvC/eS8cnXW/D95xqgnqQVDZqJI8v6WUHtVfYjhgZbjhrGa1FX0zUMHw+IIvxxD/j/ pdmc+7XfdFuqRkpSGLowdyqmQtqA8MpoU1BVdYLuezVoKe9/ik9R8Xwa5pNMe921nW2/ GrRhW9GIdhEU2kZKJMPMPCH3cFE7E+BelqG4Wc81JqvXXi+Qdddf8Oe3j8hHouwQxteL PPLe0yeWM7uJkqSKtf+ioqDs2B9dqaMeyG7wui6hMGp0+Nxw4299u5NJcXxv9Bdwm4bH RLTg1Tx0UvDYt0A620sfHD8ZB+sGjk91/2GYlu1H44O/6BkekUifSKyAadDdFsionPhy ufnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-type :content-disposition:content-transfer-encoding:in-reply-to; bh=aA5+QYWADnxObKJFy0L/8mVyN86fXPg4DK+5/MNYQGk=; b=hZYOzOjN33dfdHIwrm2kJuJ1i1A5e0oUUFHUbZ0SG7GBlG2cm7Vzw6REkg2HipS1Zw j2z44r0muFIP3EYo7ycabL7BCzeG2ZgJA0HaIdsZQkDCv1onyQaWUXaKNIDUNg2Aty2I qDkKQoMO3vw1X0LGJkaJul+cYV+FuirjDwjlavHKzIac1TA4+winpp4rZVTfgU0AKHZD aNWkECwXHyaidTRljkPQdnz7D4pwnxq2JSxBNF1BiFYpFgMsiH6MlUvfmHaL/h2DZ2Lq mwl9dUUD/YOdWZei7KKaNWIJDGYZCT+SQNUwChzlbo473xTEC26U/hoef5kHzWAR+Ifp bdoQ== X-Gm-Message-State: ALoCoQlZ6Y+P7TefpkBqIIw8yYG3KBee9EF16i2rPTkRiWLOxAsVURVdwJqIAnZ3Bcoep6HsSGh2RKrSNStd0CmaAtKFh1LLZA== X-Received: by 10.28.52.213 with SMTP id b204mr9685226wma.32.1452074471951; Wed, 06 Jan 2016 02:01:11 -0800 (PST) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id az6sm95019851wjc.25.2016.01.06.02.01.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jan 2016 02:01:11 -0800 (PST) Date: Wed, 6 Jan 2016 11:00:53 +0100 From: Adrien Mazarguil To: "Ananyev, Konstantin" Message-ID: <20160106100053.GJ12095@6wind.com> Mail-Followup-To: "Ananyev, Konstantin" , =?utf-8?B?TsOpbGlv?= Laranjeiro , "Tan, Jianfeng" , "dev@dpdk.org" References: <1451544799-70776-1-git-send-email-jianfeng.tan@intel.com> <1451544799-70776-2-git-send-email-jianfeng.tan@intel.com> <20160104113814.GT3806@6wind.com> <2601191342CEEE43887BDE71AB97725836AE1002@irsmsx105.ger.corp.intel.com> <20160105161423.GE4712@autoinstall.dev.6wind.com> <2601191342CEEE43887BDE71AB97725836AE18E3@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2601191342CEEE43887BDE71AB97725836AE18E3@irsmsx105.ger.corp.intel.com> Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set 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: Wed, 06 Jan 2016 10:01:12 -0000 On Tue, Jan 05, 2016 at 04:50:31PM +0000, Ananyev, Konstantin wrote: [...] > > -----Original Message----- > > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com] [...] > > I think we miss a comment here in how those 2/6/4 values are chosen > > because, according to the mask, I expect 16 possibilities but I get > > less. It will help a lot anyone who needs to add a new type. > > > > Extending the snprintf behavior above, it is best to remove the mask > > argument altogether and have rte_eth_dev_get_ptype_info() return the > > entire list every time. Applications need to iterate on the result in > > any case. > > I think we'd better keep mask argument. > In many cases upper layer only interested in some particular subset of > all packet types that HW can recognise. > Let say l3fwd only cares about RTE_PTYPE_L3_MASK, it is not interested in L4, > tunnelling packet types, etc. > If caller needs to know all recognised ptypes, he can set mask==-1, > In that case all supported packet types will be returned. There are other drawbacks to the mask argument in my opinion. The API will have to be updated again as soon as 32 bits aren't enough to represent all possible masks. We can't predict it will be large enough forever but on the other hand, using uint64_t seems overkill at this point. I think this use for masks should be avoided when performance does not matter much, as in this case, user application cannot know the number of entries in advance and must rely on the returned value to iterate. A helper function can be added to convert a RTE_PTYPE_* value to the layer it belongs to (using enum to define possible values). If we absolutely want a mean to filter returned values, I suggest we use this enum instead of the mask argument. Since it won't be a mask, it won't have to be updated every time a new protocol requires extending one. > > rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptypes[], > > size_t max_entries) > > > > > > > > Another point, I have read the example patch (l3fwd) but I don't > > understand why the PMD is not responsible for filling the packet type in > > the MBUF (packet parsing is done by parse_packet_type()). Why the extra > > computation? > > As I understand there are 3 possibilities now: > 1. HW supports ptype recognition and SW ptype parsing is never done > (--parse-ptype is not specified). > 2. HW supports ptype recognition, but and SW ptype parsing is done anyway > (--parse-ptype is specified). > 3. HW doesn't support and ptype recognition, and and SW ptype parsing is done > (--parse-ptype is specified). > > I suppose the question is what for introduce '--parse-ptype' at all? > My thought because of #2, so people can easily check what will be the performance impact of SW parsing. > > Konstantin > > > > > I see it more like an offload request (as checksum, etc...) and if the > > NIC does not support it then the application does the necessary overload. > > > > Best regards, > > > > -- > > Nélio Laranjeiro > > 6WIND -- Adrien Mazarguil 6WIND