From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by dpdk.org (Postfix) with ESMTP id 86F3C2BF0 for ; Fri, 26 Aug 2016 19:31:02 +0200 (CEST) Received: by mail-pa0-f47.google.com with SMTP id fi15so29098741pac.1 for ; Fri, 26 Aug 2016 10:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=NUhoRGp2qnofW9gCWrGH0j/ecaiVnX71ZnOP00iBaQ8=; b=BmtbhiRNy6/B/N8HB9NCo/1kAfyETD0L4U1t799bTa7fHPAchGHEABVxofxnhP3bVm ZS4P6w7sLG/Pl/nFFhkRMds7SxvIiIBW3BEAtjyvPPqwYSZQxEomgQ7uEwfozXBGqn5s Cf8aiGmXUnMCwnASzBJVun5Ztyy6KXI9tdsRoN60XADY4oMlu1U5t/gTPtqB5Vcb49tB 6ne0xErxej6sey2rgSOgrcGZPD57KVq4NrUDRLsXVw1XEBxiN/CC7Anh1kGMZZCcLuwx AOQAm84U3AYkX+0qlckGUv9/OqStrHmGqH7A5hrQD3FLzGWkVheznbw7S5BnYiosmtMV ODHg== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=NUhoRGp2qnofW9gCWrGH0j/ecaiVnX71ZnOP00iBaQ8=; b=Tz2TGdA9CDLsMlw7vwkbXRYh+3tKOAYMY4NwW9OKqwnaabPXc2lVm/wpwAJwlStgKI 54d8gHb4rxs66PVv9WzQMjHUiwIBgrHEqbRLDo9Wa1GOfxmP3nBfu2cgLffPh0slMOdv L7F+hJQgiWVy+Guy7sqNDNwr7BixVJ9B+7ORESFQDT/k4kXoilu0+W26BexzMNrYIafA Sp5Mit1Gw2KJiXpUC28bwB8aBiK17Hr0QYrZrUcsodCY8xIxSw/aNCRhOB2LhuaFEYp3 MBLwqd/yv/YtIj/AGsVRjosp/pmyW9vqNzaJActW2oJsa2pQWH2uoQJuTwYyHLBbvicp z5Yw== X-Gm-Message-State: AE9vXwNC2f8kkNizGFb+ZH1NULUOe38DZIlj6O2Cgv/WY/WZ7Ri0MwoefK2ijVw5XZNg0g== X-Received: by 10.66.253.7 with SMTP id zw7mr7929577pac.25.1472232661842; Fri, 26 Aug 2016 10:31:01 -0700 (PDT) Received: from xeon-e3 (static-50-53-69-251.bvtn.or.frontiernet.net. [50.53.69.251]) by smtp.gmail.com with ESMTPSA id h1sm30228125pay.48.2016.08.26.10.31.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 26 Aug 2016 10:31:01 -0700 (PDT) Date: Fri, 26 Aug 2016 10:31:14 -0700 From: Stephen Hemminger To: Tomasz Kulasek Cc: dev@dpdk.org Message-ID: <20160826103114.5b547cef@xeon-e3> In-Reply-To: <1472228578-6980-1-git-send-email-tomaszx.kulasek@intel.com> References: <1472228578-6980-1-git-send-email-tomaszx.kulasek@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 0/6] add Tx preparation 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, 26 Aug 2016 17:31:02 -0000 On Fri, 26 Aug 2016 18:22:52 +0200 Tomasz Kulasek wrote: > As discussed in that thread: > > http://dpdk.org/ml/archives/dev/2015-September/023603.html > > Different NIC models depending on HW offload requested might impose > different requirements on packets to be TX-ed in terms of: > > - Max number of fragments per packet allowed > - Max number of fragments per TSO segments > - The way pseudo-header checksum should be pre-calculated > - L3/L4 header fields filling > - etc. > > > MOTIVATION: > ----------- > > 1) Some work cannot (and didn't should) be done in rte_eth_tx_burst. > However, this work is sometimes required, and now, it's an > application issue. Why not? You are adding an additional API burden on every application. > > 2) Different hardware may have different requirements for TX offloads, > other subset can be supported and so on. These need to be reported by API so that application can handle it. Doing these transformations in tx_prep seems late in the process. > > 3) Some parameters (e.g. number of segments in ixgbe driver) may hung > device. These parameters may be vary for different devices. > > For example i40e HW allows 8 fragments per packet, but that is after > TSO segmentation. While ixgbe has a 38-fragment pre-TSO limit. Seems better to handle these limits as exceptions in i40e_tx_burst etc; rather than a pre-step. Look at how Linux driver API works, several drivers have to have an exception linearize path. > > 4) Fields in packet may require different initialization (like e.g. will > require pseudo-header checksum precalculation, sometimes in a > different way depending on packet type, and so on). Now application > needs to care about it. Once again, the driver should do this in Tx. > > 5) Using additional API (rte_eth_tx_prep) before rte_eth_tx_burst let to > prepare packet burst in acceptable form for specific device. > > 6) Some additional checks may be done in debug mode keeping tx_burst > implementation clean. Most of this could be done by refactoring existing tx_burst in drivers. Much of the code seems to be written as the "let's write a 2000 line function because that is most efficient" rather than "let's write small steps and let the compiler optimize it"