* [dpdk-dev] mlx5: the default rule makes VF rep cannot get packets @ 2019-11-25 7:27 贺鹏 2019-11-25 7:32 ` Slava Ovsiienko 0 siblings, 1 reply; 5+ messages in thread From: 贺鹏 @ 2019-11-25 7:27 UTC (permalink / raw) To: dev, matan, viacheslavo Hi, We found the patch "net/mlx5: revert default rules amount optimization", which installs a rule directing all egress traffic from VF to table 1, results in VF representors get no packets, even if there is no offload rules installed. I’ve tested both l2fwd and ovs-dpdk. However, PF rep works just fine. We are using dpdk 19.11-rc3 for evaluation. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] mlx5: the default rule makes VF rep cannot get packets 2019-11-25 7:27 [dpdk-dev] mlx5: the default rule makes VF rep cannot get packets 贺鹏 @ 2019-11-25 7:32 ` Slava Ovsiienko 2019-11-25 7:43 ` [dpdk-dev] [External] " 贺鹏 0 siblings, 1 reply; 5+ messages in thread From: Slava Ovsiienko @ 2019-11-25 7:32 UTC (permalink / raw) To: 贺鹏, dev, Matan Azrad Hi, What OFED version do you use? Or OOB kernel driver/rdma-core? Target table (1 in the mentioned patch) is created on the flow creation as empty one. The default rule for the empty ingress table in FDB (transfer attribute in testpmd command) – go to vport 0 (to wire/VF representors), it is established by kernel/rdma-core, In your setup it does not work. With best regards, Slava From: 贺鹏 <hepeng.0320@bytedance.com> Sent: Monday, November 25, 2019 9:27 To: dev@dpdk.org; Matan Azrad <matan@mellanox.com>; Slava Ovsiienko <viacheslavo@mellanox.com> Subject: mlx5: the default rule makes VF rep cannot get packets Hi, We found the patch "net/mlx5: revert default rules amount optimization", which installs a rule directing all egress traffic from VF to table 1, results in VF representors get no packets, even if there is no offload rules installed. I’ve tested both l2fwd and ovs-dpdk. However, PF rep works just fine. We are using dpdk 19.11-rc3 for evaluation. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] [External] RE: mlx5: the default rule makes VF rep cannot get packets 2019-11-25 7:32 ` Slava Ovsiienko @ 2019-11-25 7:43 ` 贺鹏 2019-11-25 8:28 ` Slava Ovsiienko 0 siblings, 1 reply; 5+ messages in thread From: 贺鹏 @ 2019-11-25 7:43 UTC (permalink / raw) To: Slava Ovsiienko; +Cc: dev, Matan Azrad Hi, > 在 2019年11月25日,下午3:32,Slava Ovsiienko <viacheslavo@mellanox.com> 写道: > > Hi, > > What OFED version do you use? Or OOB kernel driver/rdma-core? OFED 4.6-3.11. > Target table (1 in the mentioned patch) is created on the flow creation as empty one. > The default rule for the empty ingress table in FDB (transfer attribute in testpmd command) > – go to vport 0 (to wire/VF representors), it is established by kernel/rdma-core, In your setup > it does not work. > The NIC works in switchdev mode; every VF has a representer, and dpdk is polling each rep to get packets. If I revert this patch, in the probe stage, DPDK will not install the default rule which directs packets to Table 1, and dpdk can get packets. The target is to use dpdk as well as action offload together. The setup code is in the function *mlx5_flow_create_esw_table_zero_flow*. Even for running L2FWD, I cannot get a packet from VF rep. You mean this is a driver problem ? > With best regards, Slava > > From: 贺鹏 <hepeng.0320@bytedance.com> > Sent: Monday, November 25, 2019 9:27 > To: dev@dpdk.org; Matan Azrad <matan@mellanox.com>; Slava Ovsiienko <viacheslavo@mellanox.com> > Subject: mlx5: the default rule makes VF rep cannot get packets > > Hi, > > We found the patch "net/mlx5: revert default rules amount optimization", > which installs a rule directing all egress traffic from VF to table 1, results in > VF representors get no packets, even if there is no offload rules installed. > > > I’ve tested both l2fwd and ovs-dpdk. However, PF rep works just fine. > > > We are using dpdk 19.11-rc3 for evaluation. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] [External] RE: mlx5: the default rule makes VF rep cannot get packets 2019-11-25 7:43 ` [dpdk-dev] [External] " 贺鹏 @ 2019-11-25 8:28 ` Slava Ovsiienko 2019-11-25 8:32 ` 贺鹏 0 siblings, 1 reply; 5+ messages in thread From: Slava Ovsiienko @ 2019-11-25 8:28 UTC (permalink / raw) To: 贺鹏; +Cc: dev, Matan Azrad Hi, please, see below. From: 贺鹏 <hepeng.0320@bytedance.com> Sent: Monday, November 25, 2019 9:44 To: Slava Ovsiienko <viacheslavo@mellanox.com> Cc: dev@dpdk.org; Matan Azrad <matan@mellanox.com> Subject: Re: [External] RE: mlx5: the default rule makes VF rep cannot get packets Hi, 在 2019年11月25日,下午3:32,Slava Ovsiienko <viacheslavo@mellanox.com<mailto:viacheslavo@mellanox.com>> 写道: Hi, What OFED version do you use? Or OOB kernel driver/rdma-core? OFED 4.6-3.11. Target table (1 in the mentioned patch) is created on the flow creation as empty one. The default rule for the empty ingress table in FDB (transfer attribute in testpmd command) – go to vport 0 (to wire/VF representors), it is established by kernel/rdma-core, In your setup it does not work. The NIC works in switchdev mode; every VF has a representer, and dpdk is polling each rep to get packets. If I revert this patch, in the probe stage, DPDK will not install the default rule which directs packets to Table 1, and dpdk can get packets. The target is to use dpdk as well as action offload together. The setup code is in the function *mlx5_flow_create_esw_table_zero_flow*. Even for running L2FWD, I cannot get a packet from VF rep. You mean this is a driver problem ? I think so. If there is no any DPDK rule in Table 0, everything works OK, right? It means the default rule (hidden from DPDK) in table 0 works, and packets go to the vport 0 (contains all representors). If we insert jump to table 1 – nothing works, it means the default rule in table 1 fails. This one is not established by DPDK, but by the driver. With best regards, Slava With best regards, Slava From: 贺鹏 <hepeng.0320@bytedance.com<mailto:hepeng.0320@bytedance.com>> Sent: Monday, November 25, 2019 9:27 To: dev@dpdk.org<mailto:dev@dpdk.org>; Matan Azrad <matan@mellanox.com<mailto:matan@mellanox.com>>; Slava Ovsiienko <viacheslavo@mellanox.com<mailto:viacheslavo@mellanox.com>> Subject: mlx5: the default rule makes VF rep cannot get packets Hi, We found the patch "net/mlx5: revert default rules amount optimization", which installs a rule directing all egress traffic from VF to table 1, results in VF representors get no packets, even if there is no offload rules installed. I’ve tested both l2fwd and ovs-dpdk. However, PF rep works just fine. We are using dpdk 19.11-rc3 for evaluation. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] [External] RE: mlx5: the default rule makes VF rep cannot get packets 2019-11-25 8:28 ` Slava Ovsiienko @ 2019-11-25 8:32 ` 贺鹏 0 siblings, 0 replies; 5+ messages in thread From: 贺鹏 @ 2019-11-25 8:32 UTC (permalink / raw) To: Slava Ovsiienko; +Cc: dev, Matan Azrad, 张永肃, duanxiongchun Hi, I see. I am going to try OFED 4.7 official version and see if it works. Thanks. > 在 2019年11月25日,下午4:28,Slava Ovsiienko <viacheslavo@mellanox.com> 写道: > > Hi, > > please, see below. > > From: 贺鹏 <hepeng.0320@bytedance.com <mailto:hepeng.0320@bytedance.com>> > Sent: Monday, November 25, 2019 9:44 > To: Slava Ovsiienko <viacheslavo@mellanox.com <mailto:viacheslavo@mellanox.com>> > Cc: dev@dpdk.org <mailto:dev@dpdk.org>; Matan Azrad <matan@mellanox.com <mailto:matan@mellanox.com>> > Subject: Re: [External] RE: mlx5: the default rule makes VF rep cannot get packets > > Hi, > 在 2019年11月25日,下午3:32,Slava Ovsiienko <viacheslavo@mellanox.com <mailto:viacheslavo@mellanox.com>> 写道: > > Hi, > What OFED version do you use? Or OOB kernel driver/rdma-core? > OFED 4.6-3.11. > > > Target table (1 in the mentioned patch) is created on the flow creation as empty one. > The default rule for the empty ingress table in FDB (transfer attribute in testpmd command) > – go to vport 0 (to wire/VF representors), it is established by kernel/rdma-core, In your setup > it does not work. > > > The NIC works in switchdev mode; every VF has a representer, and dpdk is polling each rep to get packets. > If I revert this patch, in the probe stage, DPDK will not install the default rule which directs packets to Table 1, and dpdk can get packets. > > The target is to use dpdk as well as action offload together. > > The setup code is in the function *mlx5_flow_create_esw_table_zero_flow*. > Even for running L2FWD, I cannot get a packet from VF rep. You mean this is a driver problem ? > > I think so. If there is no any DPDK rule in Table 0, everything works OK, right? > It means the default rule (hidden from DPDK) in table 0 works, and packets go to the vport 0 > (contains all representors). If we insert jump to table 1 – nothing works, it means the default > rule in table 1 fails. This one is not established by DPDK, but by the driver. > > With best regards, Slava > > > > > > With best regards, Slava > > From: 贺鹏 <hepeng.0320@bytedance.com <mailto:hepeng.0320@bytedance.com>> > Sent: Monday, November 25, 2019 9:27 > To: dev@dpdk.org <mailto:dev@dpdk.org>; Matan Azrad <matan@mellanox.com <mailto:matan@mellanox.com>>; Slava Ovsiienko <viacheslavo@mellanox.com <mailto:viacheslavo@mellanox.com>> > Subject: mlx5: the default rule makes VF rep cannot get packets > > Hi, > > We found the patch "net/mlx5: revert default rules amount optimization", > which installs a rule directing all egress traffic from VF to table 1, results in > VF representors get no packets, even if there is no offload rules installed. > > > > I’ve tested both l2fwd and ovs-dpdk. However, PF rep works just fine. > > > We are using dpdk 19.11-rc3 for evaluation. > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-11-25 8:32 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-25 7:27 [dpdk-dev] mlx5: the default rule makes VF rep cannot get packets 贺鹏 2019-11-25 7:32 ` Slava Ovsiienko 2019-11-25 7:43 ` [dpdk-dev] [External] " 贺鹏 2019-11-25 8:28 ` Slava Ovsiienko 2019-11-25 8:32 ` 贺鹏
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).