On Sun, Apr 05, 2026 at 03:46:51PM +0200, Kirill A. Korinsky wrote:
> On Sun, 05 Apr 2026 13:52:19 +0200,
> Visa Hankala <visa@hankala.org> wrote:
> > 
> > On Sun, Apr 05, 2026 at 11:35:44AM +0200, Kirill A. Korinsky wrote:
> > > On Fri, 03 Apr 2026 16:28:34 +0200,
> > > Visa Hankala <visa@hankala.org> wrote:
> > > > 
> > > > > @@ -108,22 +110,30 @@ cn30xxpip_port_config(struct cn30xxpip_s
> > > > >  	/* SKIP=0 */
> > > > >  
> > > > >  	prt_tag = 0;
> > > > > +	SET(prt_tag, PIP_PRT_TAGN_INC_VLAN);
> > > > >  	SET(prt_tag, PIP_PRT_TAGN_INC_PRT);
> > > > 
> > > > I wonder if VLAN id and input port number should be left out from
> > > > the packet tag. This would make the tag symmetric with regards to IP
> > > > addresses and TCP/UDP ports, and let the same CPU core handle both
> > > > directions of TCP/UDP flows. This might improve CPU cache locality
> > > > and performance when forwarding multiple flows. Of course, the
> > > > symmetricity is lost if packets are transformed for example by NAT
> > > > or tunneling.
> > > >
> > > 
> > > Not sure that I get the idea of symmetric. Right now it uses SRC and DST
> > > addresses and ports, and for an opposite dirrection it should have reversed
> > > addresses and ports, isn't it?
> > 
> > By symmetric hash/tag I mean that
> > hash(saddr, sport, daddr, dport) = hash(daddr, dport, saddr, sport) .
> >
> 
> but... saddr and sport isn't mached daddr and dport.
> 
> Let assume that I send traffic from 1.2.3.4:1234 to 1.1.1.1:80, when on
> direct traffic I have as tag value hash(1.2.3.4, 1234, 1.1.1.1, 80) and when
> remote server sent something back it is hash(1.1.1.1, 80, 1.2.3.4, 1234).
> 
> What am I missing here?

The symmetry follows from the construction of the hash function.

hash(saddr, sport, daddr, dport) =
CRC(saddr || sport) ^ CRC(daddr || dport) =  (XOR is commutative)
CRC(daddr || dport) ^ CRC(saddr || sport) =
hash(daddr, dport, saddr, sport)

Above, || is catenation.