On Tue, Sep 15, 2015 at 3:24 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > From: Eric Dumazet <eduma...@google.com> > > If skb carries a l4 hash, no need to perform a flow dissection. > > Performance is slightly better : > > lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100 > 2.39012e+06 > lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100 > 2.39393e+06 > lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100 > 2.39988e+06 > > After patch : > > lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100 > 2.43579e+06 > lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100 > 2.44304e+06 > lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100 > 2.44312e+06 > > Signed-off-by: Eric Dumazet <eduma...@google.com> > Cc: Tom Herbert <t...@herbertland.com> > Cc: Mahesh Bandewar <mahe...@google.com> > --- > drivers/net/bonding/bond_main.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c > index 771a449..9250d1e 100644 > --- a/drivers/net/bonding/bond_main.c > +++ b/drivers/net/bonding/bond_main.c > @@ -3136,6 +3136,10 @@ u32 bond_xmit_hash(struct bonding *bond, struct > sk_buff *skb) > struct flow_keys flow; > u32 hash; > > + if (bond->params.xmit_policy == BOND_XMIT_POLICY_ENCAP34 && > + skb->l4_hash) > + return skb->hash; > + > if (bond->params.xmit_policy == BOND_XMIT_POLICY_LAYER2 || > !bond_flow_dissect(bond, skb, &flow)) > return bond_eth_hash(skb); > > Ugh, bond_flow_dissect is yet another instance of customized flow dissection! We should really clean this up. I suggest that in cases were we want L4 hash a call to skb_get_hash should suffice. We can create skb_get_l3hash when caller explicitly wants an L3 hash-- this would return skb->hash if it's valid and skb->l4_hash is not set, else call flow dissector with FLOW_DISSECTOR_F_STOP_AT_L3 and then do the normal hash over flow keys (don't save result in skb->hash in this case).
Tom -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
