DPDK usage discussions
 help / color / mirror / Atom feed
From: "Cao, Yahui" <yahui.cao@intel.com>
To: 胡林帆 <zhongdahulinfan@163.com>, "users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-users] i40e: The same PCTYPE with different input sets
Date: Wed, 20 Nov 2019 08:02:14 +0000
Message-ID: <69D26CF227A0D2439032A967C0D64F5C0C4BD4DE@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <53475309.aa13.16e87c44464.Coremail.zhongdahulinfan@163.com>

Hi Linfan,

        I40e HW doesn't support issue 2 rule with different input set type, for the same PCTYPE. Software by default will take the first rule as the default input set type for this PCTYPE. And If the second rule's input set is different with first rule's input set, error should be returned.

        From the log, I can see that you are using the legacy FDIR api instead of rte_flow. I'm not sure why legacy api doesn't return error for your case. Also I'm not familiar with legacy FDIR api.
        Just take rte_flow for example:
        If you issue dst ip rule for IPV4_TCP flow type and then issue dst ip + dst tcp rule for IPV4_TCP flow type in testpmd, it will return error.

testpmd> flow create 0 ingress pattern eth / ipv4 dst is 192.168.0.1 / tcp / end actions queue index 2 / end
i40e_fdir_setup(): FDIR HW Capabilities: num_filters_guaranteed = 512, num_filters_best_effort = 7168.
i40e_fdir_setup(): FDIR setup successfully, with programming queue 0.
i40e_flow_fdir_filter_programming(): filling filter programming descriptor.
i40e_flow_fdir_filter_programming(): filling transmit descriptor.
Flow rule #0 created
testpmd> flow create 0 ingress pattern eth / ipv4 dst is 192.168.0.1 / tcp dst is 34 / end actions queue index 3 / end
Caught error type 13 (specific pattern item): cause: 0x18015cf60, Conflict with the first rule's input set.: Invalid argument

Thanks.
Yahui.

-----Original Message-----
From: users <users-bounces@dpdk.org> On Behalf Of 胡林帆
Sent: Wednesday, November 20, 2019 3:44 PM
To: users@dpdk.org
Subject: Re: [dpdk-users] i40e: The same PCTYPE with different input sets

Pseudo code for the 2 flow directors


1) TCP packets with dstIP1 routes to queue1
tcp_dip_fdir()
{
    struct rte_eth_fdir_filter filter;
    memset(&filter, 0, sizeof(filter));
    filter.soft_id = 1;
    filter.input.flow_type = RTE_ETH_FLOW_NONFRAG_IPV4_TCP;
    filter.input.flow.tcp4_flow.ip.dst_ip = dip1;
    filter.input.flow.tcp4_flow.ip.proto = IPPROTO_TCP;
    filter.action.rx_queue = queue_id1;
    rte_eth_dev_filter_ctrl(portid, RTE_ETH_FILTER_FDIR, RTE_ETH_FILTER_ADD, &filter); }


2) TCP packets with dstIP2 and dstport2 routes to queue2
tcp_dip_dport_fdir()
{
    struct rte_eth_fdir_filter filter;
    memset(&filter, 0, sizeof(filter));
    filter.soft_id = 2;
    filter.input.flow_type = RTE_ETH_FLOW_NONFRAG_IPV4_TCP;
    filter.input.flow.tcp4_flow.ip.dst_ip = dip2;
    filter.input.flow.tcp4_flow.ip.proto = IPPROTO_TCP;
    filter.input.flow.tcp4_flow.dst_port = htons(dport2);
    filter.action.rx_queue = queue_id2;
    rte_eth_dev_filter_ctrl(portid, RTE_ETH_FILTER_FDIR, RTE_ETH_FILTER_ADD, &filter); }


It seems these flow directors don't work simultaneously. Only one hit and the other missed.


Best regards,
Linfan Hu
On 11/19/2019 17:03,胡林帆<zhongdahulinfan@163.com> wrote:
Hi all,
I'm using Intel XXV710, trying to set two flow director filter on the same flow type (RTE_ETH_FLOW_xxx).
First is based on TCP & dst IP:


int tcp_dip_fdir_inset(void)
{
int ret;
struct rte_eth_fdir_filter_info info;


memset(&info, 0, sizeof(info));


/* TCP && dst IP matcher */
info.info_type = RTE_ETH_FDIR_FILTER_INPUT_SET_SELECT;
info.info.input_set_conf.op = RTE_ETH_INPUT_SET_SELECT; info.info.input_set_conf.flow_type = RTE_ETH_FLOW_NONFRAG_IPV4_TCP; info.info.input_set_conf.inset_size = 1; info.info.input_set_conf.field[0] = RTE_ETH_INPUT_SET_L3_DST_IP4; ret = rte_eth_dev_filter_ctrl(port_id, RTE_ETH_FILTER_FDIR, RTE_ETH_FILTER_SET, &info); }


Second is TCP & dst IP & dst port:


int tcp_dip_dport_fdir_inset(void)
{
int ret;
struct rte_eth_fdir_filter_info info;


memset(&info, 0, sizeof(info));


/* TCP && dst IP && dst port matcher */
info.info_type = RTE_ETH_FDIR_FILTER_INPUT_SET_SELECT;
info.info.input_set_conf.op = RTE_ETH_INPUT_SET_SELECT; info.info.input_set_conf.flow_type = RTE_ETH_FLOW_NONFRAG_IPV4_TCP; info.info.input_set_conf.inset_size = 2; info.info.input_set_conf.field[0] = RTE_ETH_INPUT_SET_L3_DST_IP4; info.info.input_set_conf.field[1] = RTE_ETH_INPUT_SET_L4_TCP_DST_PORT;
ret = rte_eth_dev_filter_ctrl(port_id, RTE_ETH_FILTER_FDIR, RTE_ETH_FILTER_SET, &info); }


Then I set the flow director rules for the two input set.  I found that only the last one works!
So I went deep into the i40e PMD driver, and found that if I set two input set for a flow type (RTE_ETH_FLOW_xxx), then the second one will overide the first one. If I change op from RTE_ETH_INPUT_SET_SELECT to RTE_ETH_INPUT_SET_ADD, then I found that only tcp_dip_dport_fdir works:


int
i40e_fdir_filter_inset_select(struct i40e_pf *pf, struct rte_eth_input_set_conf *conf) { if (conf->op == RTE_ETH_INPUT_SET_SELECT) inset_reg &= I40E_REG_INSET_FLEX_PAYLOAD_WORDS;
else
input_set |= pf->fdir.input_set[pctype]; }


Intel® Ethernet Controller X710/ XXV710/XL710 Datasheet, part 7.1.9 describes the FD matching criteria:
Filter Match Criteria — A packet matches a filter entry if the following conditions are met:
a. The target VSI equals to the programmed DEST_VSI.
b. The identified PCTYPE equals to the programmed PCTYPE.
c. The received packet pattern matches the programmed one (the relevant fields for the PCTYPE as defined by the FD input set listed in Table 7-5).


My question is:
Can we use (TCP & dst IP) and (TCP & dst IP & dst port) flow director simultaneously?
Or to be more general, same PCTYPE with different input set?
| |
Linfan Hu
|
|
zhongdahulinfan@163.com
|
签名由网易邮箱大师定制

  reply	other threads:[~2019-11-20  8:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-18  9:48 胡林帆
2019-11-20  7:43 ` 胡林帆
2019-11-20  8:02   ` Cao, Yahui [this message]
2019-11-20  9:05     ` 胡林帆
2019-11-19  1:39 胡林帆

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=69D26CF227A0D2439032A967C0D64F5C0C4BD4DE@SHSMSX101.ccr.corp.intel.com \
    --to=yahui.cao@intel.com \
    --cc=users@dpdk.org \
    --cc=zhongdahulinfan@163.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK usage discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/users/0 users/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 users users/ https://inbox.dpdk.org/users \
		users@dpdk.org
	public-inbox-index users

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.users


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git