> -----Original Message----- > From: Or Gerlitz [mailto:gerlitz.or@xxxxxxxxx] > Sent: Monday, July 16, 2018 2:24 PM > To: Mark Bloch <markb@xxxxxxxxxxxx> > Cc: Doug Ledford <dledford@xxxxxxxxxx>; Jason Gunthorpe > <jgg@xxxxxxxxxxxx>; Leon Romanovsky <leonro@xxxxxxxxxxxx>; RDMA > mailing list <linux-rdma@xxxxxxxxxxxxxxx>; Saeed Mahameed > <saeedm@xxxxxxxxxxxx>; linux-netdev <netdev@xxxxxxxxxxxxxxx> > Subject: Re: [RFC PATCH rdma-next 13/18] RDMA/mlx5: Enable decap and > packet reformat on flow tables > > On Mon, Jul 16, 2018 at 11:23 AM, Leon Romanovsky <leon@xxxxxxxxxx> > wrote: > > From: Mark Bloch <markb@xxxxxxxxxxxx> > > > > If NIC RX flow tables support decap opertion, enable it on creation. > > opertion --> operation > > > If NIC TX flow tables support reformat opertion, enable it on creation. > > What is the trigger to use the decap flag on RX table or encap flag on > TX table? > It has no performance penalty to always enable that, so that's what I do if supported. > Please note that we have a short blanket w.r.t mutual usage by FDB and NIC steering tables have different limitations, so encap/decap on NIC steering have nothing to do with the limitations the FDB has with those operations. > NIC vs e-Switch steering, did you consider to do that on demand? The flow table needs to be created with those flags set if we want to attach decap/packet reformat action to it. BTW, there is no modify action for those bits so that's why I'm doing it on creation. Mark ��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
