From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by dpdk.org (Postfix) with ESMTP id 8120A594B for ; Fri, 3 Jan 2014 20:51:32 +0100 (CET) Received: by mail-wi0-f171.google.com with SMTP id bz8so839611wib.16 for ; Fri, 03 Jan 2014 11:52:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=dumYTeKtY9WEvKKND0z7MCiGnXatvHJZRs1Sxp30Mes=; b=mY9CoVpPAAznWoiDHNmgdbdhEK71szKUuPzUHb8QEOleDXNTgvoiIV8U3QPLbO8Hao Ame20nlnwZHaTKD5+BqQhypM79AcMcflmq2JlsCyQOaCbcsAID9jAfKuJ7zA+457lQx/ 9DSjve/Y7/O7PqbcO9lV6bBp+lqQiB6akfH7oqmGz594tXMoHUBbkAd6zmxpDS4qrb6E yewZ/nXbfJfzTM5RjIOd89fdyJCrHmR5W3rTnUMrUP7ghLX/DIh+s3EHs7wRsWwkGWhe DkHpW8H14r/i5QFu85Z43FBSk17MEmsRvNZCIlI+yhyl/mO03R8InBqlzQXeLs889rUc jD9w== X-Gm-Message-State: ALoCoQlMBEI5taQcprlGYeB7BA6IA19fnjDx8qyqgasewjdijB/YWCfVsV93sgSdBJnlXAAWwnoy MIME-Version: 1.0 X-Received: by 10.180.149.175 with SMTP id ub15mr3278375wib.10.1388778763021; Fri, 03 Jan 2014 11:52:43 -0800 (PST) Received: by 10.216.20.202 with HTTP; Fri, 3 Jan 2014 11:52:42 -0800 (PST) Date: Fri, 3 Jan 2014 14:52:42 -0500 Message-ID: From: Robert Sanford To: dev@dpdk.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] Comments regarding Flow Director support in PMD IXGBE 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, 03 Jan 2014 19:51:32 -0000 Hi, We would like your opinions on the following observations, regarding the 82599 Flow Director support. Issue #1: Our reading of the 82599 data sheet leads us to believe that Flow Director can simultaneously handle *both* IPv4 and IPv6 filters, with separate filter rules, of course. Thus, at the bottom of ixgbe_fdir.c:fdir_set_input_mask_82599( ), we could remove the "if (!input_mask->set_ipv6_mask)" / "else" around the setting of FDIRSIP4M, FDIRDIP4M, and FDIRIP6M. (This would also eliminate the need for the set_ipv6_masks flag itself.) We performed limited testing on this change. We have successfully added both IPv4 and IPv6 signature filters, but so far have only exercised them with IPv4 traffic. One would think that the designers of this chip feature envisioned users filtering mixed traffic (both IPv4 and IPv6). Issue #2: Apparently, API rte_eth_dev_fdir_set_masks( ) expects IPv4 address and port masks in host-byte-order (little-endian), while rte_eth_dev_fdir_add_signature_filter( ) expects IPv4 addresses and ports in network-byte-order (big-endian). (Contrast the writing into IXGBE_FDIRSIP4M in ixgbe_fdir.c: fdir_set_input_mask_82599( ), versus ixgbe/ixgbe_82599.c: ixgbe_fdir_set_input_mask_82599( ). The former includes an extra IXGBE_NTOHL( ) on the mask's complement.) Not knowing this made it a bit tricky to get signature filters working properly. Perhaps it is too late to change the byte-ordering in the (set masks) API? Whether we change it or not, we probably should at least document these details, to avoid confusion. -- Regards, Robert