From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id D31E63238 for ; Thu, 27 Oct 2016 17:01:24 +0200 (CEST) Received: by mail-wm0-f52.google.com with SMTP id n67so49576952wme.1 for ; Thu, 27 Oct 2016 08:01:24 -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=13QxM3+NKIdoovyLs5gCzXm/WhGfjpCR/VCT+vcW5Wk=; b=hSjg+UHtBmL+RDo+8moZtfH9gvLS/OQwbCMedQqSeIV6QdX4ij0RO8Zq0cWDOLbE50 +vlAbk6ht9WSTEEIyaxB4GSGytHKlQPmaIwk4/8ABR8TRxyfojZsLQ1HgQ941mGeO5cg NX5TsnHT3H677OmKnKD7eVQphTzxrwmD63cbXSwLm3dq7yR9ToPXmVQmqUvOHzqIHSfq 5PXlWkk5VN3pYrPAa0QuitPVBG/klOMRcoMYhLuPW5m8FOm4/cGwd+RrQpyY+Y3JM2us E2yeFJ1blcaknAGk3FVQz4MpaA9PGqzwMeSRZnTZQAI/14fXJ84Y2DgiMLmtR0O5vMaj Ljkw== 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=13QxM3+NKIdoovyLs5gCzXm/WhGfjpCR/VCT+vcW5Wk=; b=gO3RV7FwkpK5UIuDy/tSGGI35xmiJZj3TeAKGzApa7cVxlMRR7tA8JvKOuwGVe30H3 vbsW7GyziKTZ+c8v8IiCyLmV+RG7q+pHo934WjhSi62p9xeaSIwuHvkieStSwDFPHjJP 62ludhFkOLITfRTAsYyedYBTvFmvJbwyn9GaVQRj+iCj9w77TavHw5zqeLNQW2AKVV6S EPpxI6ttPSWpiJGIbu78U/RkPwyzasCmHHp+CXfw+hbYABGtQI/vuh8zt/n/71BMAovy Ez8bbSVb6yxri+TYBb4miQjOsD8IVV8rIxyIUb8J00Z6WGWQqXEBfW6zXSAbu6sDQEww sxPg== X-Gm-Message-State: ABUngvcy5AAcFocGXOWw3vuEG7fF5yYhXPINDcVL1jSzp/NGyeEds9XfziRxDyiqdoAbQawC X-Received: by 10.28.197.67 with SMTP id v64mr13742600wmf.9.1477580484436; Thu, 27 Oct 2016 08:01:24 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id pe5sm8959315wjb.15.2016.10.27.08.01.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Oct 2016 08:01:23 -0700 (PDT) From: Thomas Monjalon To: Tomasz Kulasek Date: Thu, 27 Oct 2016 17:01:22 +0200 Message-ID: <1499338.8Le0ABsxDG@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1477486575-25148-2-git-send-email-tomaszx.kulasek@intel.com> References: <1477327917-18564-1-git-send-email-tomaszx.kulasek@intel.com> <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com> <1477486575-25148-2-git-send-email-tomaszx.kulasek@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org 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: Thu, 27 Oct 2016 15:01:25 -0000 Hi Tomasz, This is a major new function in the API and I still have some comments. 2016-10-26 14:56, Tomasz Kulasek: > --- a/config/common_base > +++ b/config/common_base > +CONFIG_RTE_ETHDEV_TX_PREP=y We cannot enable it until it is implemented in every drivers. > struct rte_eth_dev { > eth_rx_burst_t rx_pkt_burst; /**< Pointer to PMD receive function. */ > eth_tx_burst_t tx_pkt_burst; /**< Pointer to PMD transmit function. */ > + eth_tx_prep_t tx_pkt_prep; /**< Pointer to PMD transmit prepare function. */ > struct rte_eth_dev_data *data; /**< Pointer to device data */ > const struct eth_driver *driver;/**< Driver for this device */ > const struct eth_dev_ops *dev_ops; /**< Functions exported by PMD */ Could you confirm why tx_pkt_prep is not in dev_ops? I guess we want to have several implementations? Shouldn't we have a const struct control_dev_ops and a struct datapath_dev_ops? > +rte_eth_tx_prep(uint8_t port_id, uint16_t queue_id, struct rte_mbuf **tx_pkts, > + uint16_t nb_pkts) The word "prep" can be understood as "prepend". Why not rte_eth_tx_prepare? > +/** > + * Fix pseudo header checksum > + * > + * This function fixes pseudo header checksum for TSO and non-TSO tcp/udp in > + * provided mbufs packet data. > + * > + * - for non-TSO tcp/udp packets full pseudo-header checksum is counted and set > + * in packet data, > + * - for TSO the IP payload length is not included in pseudo header. > + * > + * This function expects that used headers are in the first data segment of > + * mbuf, are not fragmented and can be safely modified. What happens otherwise? > + * > + * @param m > + * The packet mbuf to be fixed. > + * @return > + * 0 if checksum is initialized properly > + */ > +static inline int > +rte_phdr_cksum_fix(struct rte_mbuf *m) Could we find a better name for this function? - About the prefix, rte_ip_ ? - About the scope, where this phdr_cksum is specified? Isn't it an intel_phdr_cksum to match what hardware expects? - About the verb, is it really fixing something broken? Or just writing into a mbuf? I would suggest rte_ip_intel_cksum_prepare.