On Sat, Mar 6, 2021 at 6:48 PM Vladimir Oltean <olte...@gmail.com> wrote: > > On Sat, Mar 06, 2021 at 06:04:14PM +0530, Sunil Kovvuri wrote: > > On Sat, Mar 6, 2021 at 5:47 AM Andrew Lunn <and...@lunn.ch> wrote: > > > > > > On Fri, Mar 05, 2021 at 03:07:02PM -0800, Jakub Kicinski wrote: > > > > On Fri, 5 Mar 2021 16:15:51 +0530 Sunil Kovvuri wrote: > > > > > Hi, > > > > > > > > > > We have a requirement where in we want RSS hashing to be done on > > > > > packet fields > > > > > which are not currently supported by the ethtool. > > > > > > > > > > Current options: > > > > > ehtool -n <dev> rx-flow-hash > > > > > tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6 m|v|t|s|d|f|n|r > > > > > > > > > > Specifically our requirement is to calculate hash with DSA tag (which > > > > > is inserted by switch) plus the TCP/UDP 4-tuple as input. > > > > > > > > Can you share the format of the DSA tag? Is there a driver for it > > > > upstream? Do we need to represent it in union ethtool_flow_union? > > > > > > Sorry, i missed the original question, there was no hint in the > > > subject line that DSA was involved. > > > > > > Why do you want to include DSA tag in the hash? What normally happens > > > with DSA tag drivers is we detect the frame has been received from a > > > switch, and modify where the core flow dissect code looks in the frame > > > to skip over the DSA header and parse the IP header etc as normal. > > > > I understand your point. > > The requirement to add DSA tag into RSS hashing is coming from one of > > our customer. > > > > > > > > Take a look at net/core/flow_dissect.c:__skb_flow_dissect() > > > > > > This fits with the core ideas of the network stack and offloads. Hide > > > the fact an offload is being used, it should just look like a normal > > > interface. > > > > > > Andrew > > > > Yes, the pkt will look like a normal packet itself. > > In our case HW strips the DSA tag from the packet and forwards it to a VF. > > DSA-aware SR-IOV on master, very interesting. I expect that the reverse > is true as well: on xmit, the VF will automatically insert a FWD tag > into the packet too, which encodes a 'virtual' source port and switch id.
Yes, HW inserts the tag on the transmit side automatically. > > What Marvell controller is this? How is the SR-IOV implemented in the > kernel, is it modeled as switchdev, with host representors for the VFs? This is Marvell OcteonTx2/CN10K RVU controller drivers/net/ethernet/marvell/octeontx2. And no the controller doesn't have a internal switch and hence currently there is no switchdev support. The switch I referred to is an external one whose CPU port is connected to this controller. > Does it support VEPA mode or VEB too? If it supports VEB, does it learn > (more like 'steal') addresses from the DSA switch's FDB? Does it also > push addresses into the DSA switch's FDB? > > To your question: why stop at hashing? What about flow steering? > What does your hardware actually support? It is obvious that it has deep > parsing of Marvell DSA tags specifically, so the generic 'masked u32 key' > matching may not be the best way to model this. Can your DSA master even > perform masked matching on generic u32 keys, or are you planning to just > look for the particular pattern of a Marvell DSA tag in the ethtool > rxnfc callbacks, and reject anything that doesn't match? The parser in the HW is configurable and can parse any header with a mask. Thanks, Sunil.
