From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com [209.85.128.174]) by dpdk.org (Postfix) with ESMTP id 97110326B for ; Tue, 4 Apr 2017 14:45:59 +0200 (CEST) Received: by mail-wr0-f174.google.com with SMTP id w43so212744156wrb.0 for ; Tue, 04 Apr 2017 05:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=+Bgv3aDMSaeYkU05tsRPE+9a7ZK1sSgRlauWQn97e7g=; b=Nw5+C2L9WmuROpS74/7npu+3QbLLUNVnm0hQJiwnVgTm+sDCeXC3YCmTDKF7P8BQtt qpjPzcey0XSdGkRket5OIH+U9dOhk4LrbBvILEYxYsIydOsvyc2wGXFc4b7k2mCrEOp9 e4WpeQ7vfLRisfUGrFCPl1Lex8yESrWJfdYWoHK2jWhc9pmA3SQhaEaYUVAquN13CWiw zy06YIg1Z0VIObcFdrB+bLDSBcNv+kAeuneg+a/ozCodYF5vqwSLHh5A0cMJb8iqgrjw P/8pcHcpdRkTKd0FDSpoAeG+wQh0SwhfxjH7tYpBQ483IQcZV6JUwDNmooxFDwPabmvd iAsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=+Bgv3aDMSaeYkU05tsRPE+9a7ZK1sSgRlauWQn97e7g=; b=kZ8bLnhG5Ij6mr3TN08jaK/nxqB9mTZJp/NkYAFXyZVejtbw1h/0Thcc71N09qI01x gG3PlLz8FXwVU9HkbJVCR0/O0NkMGMPOrh78HNUkkUFgyCWoGOFzzmGP2tErtGN4QjQC ZCLoSbva2X8Uylts7uECjDgDGK8AxnMShdo4Pq4EZQoB0oOEI4wnPYn7mrlLcIUyGtZh mqHvQ2HOxRKl5bZKO3YoEfTpbEeKA8e5Bc03sNxEXjwwDE9T492E4RQKrX3JjZ33hykL E8y4hyl/hgxiVhnZjO9LsQ8x/Vvjn8lvKAYb1u3hvEngnJrcKV2lR/Fi7SFgNhVNA7jU 7jeA== X-Gm-Message-State: AFeK/H0s34xyHJi9ITlcxYGOgtgOJvlMplv0gWBvoMdBPkWoLAj3BXD4q31bEK/ZQPaKiq+0 X-Received: by 10.223.142.172 with SMTP id q41mr1449899wrb.25.1491309958597; Tue, 04 Apr 2017 05:45:58 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id o196sm18382678wmg.12.2017.04.04.05.45.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 05:45:57 -0700 (PDT) From: Thomas Monjalon To: "Liu, Yong" Cc: "Tan, Jianfeng" , dev@dpdk.org Date: Tue, 04 Apr 2017 14:45:56 +0200 Message-ID: <2707753.Svae6e0B9N@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <86228AFD5BCD8E4EBFD2B90117B5E81E62D5E3E2@SHSMSX103.ccr.corp.intel.com> References: <1485156509-4919-1-git-send-email-yong.liu@intel.com> <2819058.cfIqcf5N9Z@xps13> <86228AFD5BCD8E4EBFD2B90117B5E81E62D5E3E2@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 1/3] examples/ip_reassembly: add parse-ptype option 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, 04 Apr 2017 12:45:59 -0000 2017-02-10 09:02, Liu, Yong: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2017-02-10 07:53, Liu, Yong: > > > From: Thomas Monjalon > > > > 2017-02-09 22:25, Marvin Liu: > > > > > Add new option parse-ptype in this sample in case of pmd driver > > > > > not provide packet type info. If this option enabled, packet type > > > > > will be analyzed in Rx callback function. > > > > [...] > > > > > + if (parse_ptype) { > > > > > + if (add_cb_parse_ptype(portid, queueid) < 0) > > > > > + rte_exit(EXIT_FAILURE, > > > > > + "Fail to add ptype cb\n"); > > > > > + } else if (!check_ptype(portid)) > > > > > + rte_exit(EXIT_FAILURE, > > > > > + "PMD can not provide needed ptypes\n"); > > > > > > > > Instead of adding a new option, why not adding the callback > > automatically > > > > if the packet type is not supported by the hardware? > > > > > > Thomas, > > > We want to let user choice which kind of method for packet type parsing. > > > If start application with parse-type option, is meaning user want to use > > software parsing otherwise will use hardware parsing. > > > > I do not understand why this user choice matters. > > If it is available, hardware ptype is better, isn't it? > > It it is not available, we need to be aware of this specific issue, > > otherwise we have the error "PMD can not provide needed ptypes" > > (without suggesting to use the option). > > Yes, hardware always has better performance than software. I think it matters in some performance measurement scenarios. > Like l3fwd, we compared performance with software and hardware packet parsers and this option may not have much value in other samples. > I will rework this patch and fallback to software if hardware not support. The ip_fragmentation case has been reworked this way: http://dpdk.org/patch/21769