[dpdk-dev] [PATCH v3 1/2] net/i40e: queue region set and flush

Zhao1, Wei wei.zhao1 at intel.com
Mon Sep 25 04:55:02 CEST 2017


Hi, Andrey

> -----Original Message-----
> From: Chilikin, Andrey
> Sent: Saturday, September 23, 2017 4:14 AM
> To: Zhao1, Wei <wei.zhao1 at intel.com>; dev at dpdk.org
> Cc: Yigit, Ferruh <ferruh.yigit at intel.com>; Xing, Beilei
> <beilei.xing at intel.com>; Wu, Jingjing <jingjing.wu at intel.com>
> Subject: RE: [dpdk-dev] [PATCH v3 1/2] net/i40e: queue region set and flush
> 
> Hi Wei
> 
> > -----Original Message-----
> > From: Zhao1, Wei
> > Sent: Friday, September 22, 2017 9:49 AM
> > To: Chilikin, Andrey <andrey.chilikin at intel.com>; dev at dpdk.org
> > Cc: Yigit, Ferruh <ferruh.yigit at intel.com>; Xing, Beilei
> > <beilei.xing at intel.com>; Wu, Jingjing <jingjing.wu at intel.com>
> > Subject: RE: [dpdk-dev] [PATCH v3 1/2] net/i40e: queue region set and
> > flush
> >
> > Hi,Andrey
> >
> > > -----Original Message-----
> > > From: Chilikin, Andrey
> > > Sent: Friday, September 22, 2017 3:53 AM
> > > To: Zhao1, Wei <wei.zhao1 at intel.com>; dev at dpdk.org
> > > Cc: Zhao1, Wei <wei.zhao1 at intel.com>; Yigit, Ferruh
> > > <ferruh.yigit at intel.com>; Xing, Beilei <beilei.xing at intel.com>; Wu,
> > > Jingjing <jingjing.wu at intel.com>
> > > Subject: RE: [dpdk-dev] [PATCH v3 1/2] net/i40e: queue region set
> > > and
> > flush
> 
> <snip>
> 
> > > > +	if (i == I40E_REGION_MAX_INDEX) {
> > > > +		printf("The region sizes should be any of the following "
> > > > +		"values: 1, 2, 4, 8, 16, 32, 64 as long as the "
> > > > +		"total number of queues do not exceed the VSI allocation");
> 
>  printf?

Yes, just a reminder for user, you think I should use " PMD_INIT_LOG( )" instead?
I will change to that.

> 
> > > > +		return ret;
> > > > +	}
> > > > +
> > > > +	if (conf_ptr->region_id >= I40E_REGION_MAX_INDEX) {
> > > > +		PMD_INIT_LOG(ERR, "the queue region max index is 7");
> > > > +		return ret;
> > > > +	}
> > > > +
> 
> <snip>
> > > > +	switch (op_type) {
> > > > +	case RTE_PMD_I40E_QUEUE_REGION_SET:
> > > > +		ret = i40e_set_queue_region(pf, conf_ptr);
> > > > +		break;
> > > > +	case RTE_PMD_I40E_REGION_FLOWTYPE_PF_SET:
> > > > +		ret = i40e_set_region_flowtype_pf(hw, pf, conf_ptr);
> > > > +		break;
> > > > +	case RTE_PMD_I40E_REGION_FLOWTYPE_VF_SET:
> > > > +		ret = -EINVAL;
> > > > +		break;
> > >
> > > Why setting of flowtype mapping is separated to two different option?
> > > Does it mean that application will need to detect which driver it
> > > uses before calling this API? Application should not care which
> > > driver is in use, it tracks
> > the
> > > number of queues used for RSS and just configures these queues to
> > > different regions, regardless if it runs on top of PF or VF.
> > > Difference in configuration for PF/VF should be hidden from
> > > application, so only single RTE_PMD_I40E_REGION_FLOWTYPE_SET
> should be used.
> >
> > By now , we only support pf for this config.
> > But I think what you said is very reasonable. I can change code to a
> > new
> > scheme:
> > DPDK i40e driver use   rte_eth_dev ->device->name to detect  whether his
> > name is
> > " net_i40e_vf " or " net_i40e"  itself, then  we  can PMD driver
> > decide to config PFQF_HREGION or VFQF_HREGION.
> > I will make change in v4 later.
> >
> > >
> > > All other options do not have separate check.
> > > Will they work on both PF and VF?
> >
> > No, only WORK on PF. The reason we have talk in other mail before.
> >
> 
> Yes, it is why I was confused with separating
> RTE_PMD_I40E_REGION_FLOWTYPE to PF and VF. All options work on PF
> only, by only FLOWTYPE was split to PF/VF.

Yes,   I will point out that only pf support in commit log in v4.

> 
> > >
> > > > +	case RTE_PMD_I40E_UP_REGION_SET:
> > > > +		ret = i40e_set_up_region(pf, conf_ptr);
> > > > +		break;
> > > > +	case RTE_PMD_I40E_REGION_ALL_FLUSH_ON:
> > > > +		ret = i40e_flush_region_all_conf(hw, pf, 1);
> > > > +		break;
> > > > +	case RTE_PMD_I40E_REGION_ALL_FLUSH_OFF:
> > > > +		ret = i40e_flush_region_all_conf(hw, pf, 0);
> > > > +		break;
> > > > +
> 
> Could you explain what is the difference between FLUSH_OFF and
> FLUSH_ON and how it can be used by an application?

ALL config from CLI at first will only keep in DPDK software stored in driver, only after " FLUSH_ON ", it commit all configure to HW.
Because I have to set hardware config at a time, so I have to record all CLI command at first.
" FLUSH_OFF " is just clean all configuration about queue region  just now, and restore all to DPDK i40e driver default config when start up.
The following is my test process in CLI: 

./x86_64-native-linuxapp-gcc/app/testpmd -c 1ffff -n 4 -- -i --nb-cores=8  --rxq=8 --txq=8 --port-topology=chained
set fwd rxonly
port config all rss all
queue-region set port 0 region_id 0 queue_start_index 2 queue_num 2 
queue-region set port 0 region_id 1 queue_start_index 4 queue_num 2 
queue-region set pf port 0 region_id 0 flowtype 31
queue-region set pf port 0 region_id 1 flowtype 33
queue-region set pf port 0 region_id 1 flowtype 34
queue-region set port 0 UP 1 region_id 0
queue-region set port 0 UP 3 region_id 1
queue-region flush on  port 0
start
set verbose 1
sendp([Ether(dst="3C:FD:FE:9F:70:B8", src="52:00:00:00:00:00")/Dot1Q(prio=3)/IP(src="10.0.0.1",dst="192.168.0.2")/TCP(dport=80, sport=80 )/("X"*48)], iface="ens5f2", count=10)
sendp([Ether(dst="3C:FD:FE:9F:70:B8", src="52:00:00:00:00:00")/IP(src="10.0.0.1",dst="192.168.0.2")/SCTP(dport=80, sport=80 )/("X"*48)], iface="ens5f2", count=10)
sendp([Ether(dst="3C:FD:FE:9F:70:B8", src="52:00:00:00:00:00")/IP(src="10.0.0.1",dst="192.168.0.2")/UDP(dport=80, sport=80 )/("X"*48)], iface="ens5f2", count=10)

> 
> > > > +	default:
> > > > +		PMD_DRV_LOG(WARNING, "op type (%d) not supported",
> > > > +			    op_type);
> > > > +		ret = -EINVAL;
> > > > +		break;
> > > > +	}
> > > > +
> > > > +	I40E_WRITE_FLUSH(hw);
> > > > +
> > > > +	return ret;
> > > > +}
> > >
> >
> > > How this API can be tested, is there a separate testpmd patch?
> >
> > Yes, testpmd has add new CLI commands to support it, also can be use
> > by customer.
> 
> Sorry, missed second part of the patchset.
> 
> Regards,
> Andrey


More information about the dev mailing list