From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id 22E4C5681 for ; Fri, 4 Nov 2016 12:35:53 +0100 (CET) Received: by mail-wm0-f54.google.com with SMTP id t79so43892330wmt.0 for ; Fri, 04 Nov 2016 04:35:53 -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=zmM6LcK6UluPkwZnL8bPNeVSNbTZcX9nNQa1qDU4vQU=; b=IHvcgS5A/0moK6PxqwyAPcJvTRL4C7EMCtcCbZwIqnTLOBXOPJhCN30BIPvKhz11Ig LsP+eoqxHeI70vYfQ/SQFRumGd0/rljUbXo0vr8n5YCm4N+JNBOSMhWwttL5scTln1HU 1rfcf/8e0Mbjyoli4EJrMpwKP+G9RUeQKJ4L+0HGlegsTLZwcynfFa+08GlIirsDPL7R 5YWBSZ2wSg929daEsuoKNuuHbgOZddnXoL8csH12Rz2Cyx5BOLw2u97U38yTNdM8hI6b fgtfeSpbwzJEuq6l8r3C1H2ImhYGn22JwJjE1/gPBn1yMV+aGHmRXkiz5hdEvzuBFhxy IURA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=zmM6LcK6UluPkwZnL8bPNeVSNbTZcX9nNQa1qDU4vQU=; b=YRDGayjT0NZfsYsmb38NU9on0Du1bYTC89zKlTNkj8JZDjSvCXjYBpN+/fsqUAnEsy WBkdlPIsHgpldVCmLwC+Ocvh48bH07hhQTWUOw3eQRYfyMtkjTWVauSgThZnFbrBMjjF 7yxge1xdu+/+lUQ8bZWFrz6JgliNt4SwlsgN57hL4nQ7ILUU3tKSFshgzKnTT5GbrhK3 ksDXxBlrgE/gMCIbXfKdWuTOfWUcVsnZE654u4RKg2ul1Qca5ej7d1lFWZ3mQqQGgpOq wz0njN5X+4dW8XqizwPZoc2a8C1J91Gpl3YQRLd8KMQu9hXSo6pnUpu7DELcG1vj1i6p EPKQ== X-Gm-Message-State: ABUngvcZkXV2emPP2EvPbF5rMg64cMXj6zAV312G7RDL+dGKx7kSQwVXMK7wp6b27vyR0HLW X-Received: by 10.28.180.214 with SMTP id d205mr3138983wmf.131.1478259352738; Fri, 04 Nov 2016 04:35:52 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id 130sm4159097wmf.0.2016.11.04.04.35.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 04:35:52 -0700 (PDT) From: Thomas Monjalon To: "Ananyev, Konstantin" Cc: dev@dpdk.org Date: Fri, 04 Nov 2016 12:35:50 +0100 Message-ID: <2032081.JWNxJ3JKje@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0CF990@irsmsx105.ger.corp.intel.com> References: <1477327917-18564-1-git-send-email-tomaszx.kulasek@intel.com> <2177010.quNaxrZShx@xps13> <2601191342CEEE43887BDE71AB9772583F0CF990@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v11 1/6] ethdev: 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, 04 Nov 2016 11:35:53 -0000 2016-11-01 12:57, Ananyev, Konstantin: > > > > I suggest to integrate it in the beginning of 17.02 cycle, with the hope > > > > that you can convince other developers to implement it in other drivers, > > > > so we could finally enable it in the default config. > > > > > > Ok, any insights then, how we can convince people to do that? > > > > You just have to explain clearly what this new feature is bringing > > and what will be the future possibilities. > > > > > BTW, it means then that tx_prep() should become part of mandatory API > > > to be implemented by each PMD doing TX offloads, right? > > > > Right. > > The question is "what means mandatory"? > > For me "mandatory" here would mean that: > - if the PMD supports TX offloads AND > - if to be able use any of these offloads the upper layer SW would have to: > - modify the contents of the packet OR > - obey HW specific restrictions > then it is a PMD developer responsibility to provide tx_prep() that would implement > expected modifications of the packet contents and restriction checks. > Otherwise, tx_prep() implementation is not required and can be safely set to NULL. > > Does it sounds good enough to everyone? Yes, good definition, thanks. > > Should we block some patches for non-compliant drivers? > > If we agree that it should be a 'mandatory' one - and patch in question breaks > that requirement, then probably yes. > > > Should we remove offloads capability from non-compliant drivers? > > Do you mean existing PMDs? > Are there any particular right now, that can't work properly with testpmd csumonly mode? I cannot answer to this question. Before txprep, there is only one API: the application must prepare the packets checksum itself (get_psd_sum in testpmd). With txprep, the application have 2 choices: keep doing the job itself or call txprep which calls a PMD-specific function. The question is: does non-Intel drivers need a checksum preparation for TSO? Will it behave well if txprep does nothing in these drivers? When looking at the code, most of drivers handle the TSO flags. But it is hard to know whether they rely on the pseudo checksum or not. git grep -l 'PKT_TX_UDP_CKSUM\|PKT_TX_TCP_CKSUM\|PKT_TX_TCP_SEG' drivers/net/ drivers/net/bnxt/bnxt_txr.c drivers/net/cxgbe/sge.c drivers/net/e1000/em_rxtx.c drivers/net/e1000/igb_rxtx.c drivers/net/ena/ena_ethdev.c drivers/net/enic/enic_rxtx.c drivers/net/fm10k/fm10k_rxtx.c drivers/net/i40e/i40e_rxtx.c drivers/net/ixgbe/ixgbe_rxtx.c drivers/net/mlx4/mlx4.c drivers/net/mlx5/mlx5_rxtx.c drivers/net/nfp/nfp_net.c drivers/net/qede/qede_rxtx.c drivers/net/thunderx/nicvf_rxtx.c drivers/net/virtio/virtio_rxtx.c drivers/net/vmxnet3/vmxnet3_rxtx.c