Re: [PATCH net-next] tc: fix tc actions in case of shared skb

[Alexei Starovoitov <ast@plumgrid.com>]

On 7/13/15 1:04 PM, David Miller wrote:
> From: Alexei Starovoitov <ast@plumgrid.com>
> Date: Mon, 13 Jul 2015 12:47:42 -0700
>
>> In all normal cases skb->users == 1, but pktgen is using trick:
>> atomic_add(burst, &skb->users);
>> so when testing something like:
>
> You can want pktgen rx (which is the only buggy case as far as I can
> see, TX is fine) to run fast, but you must do so by abiding by the
> appropriate SKB sharing rules.
>
> You can't do an optimization in pktgen for RX processing that works
> "some of the time".  We have shared SKB rules for a reason.
>
> And I don't want to have to explain to someone in the future why that
> drop check is there, and have to tell them "because pktgen is broken
> and we decided to add a hack here rather than make pktgen send
> properly formed SKBs into the RX path"
>
> Ok?

in general all makes sense, but it is both RX and TX.
Without burst hack we cannot achieve line rate TX.
         atomic_add(burst, &pkt_dev->skb->users);
xmit_more:
         ret = netdev_start_xmit(pkt_dev->skb, odev, txq, --burst > 0);

in pktgen we check that driver can work with users > 1 via:
pkt_dev->odev->priv_flags & IFF_TX_SKB_SHARING

so real hw driver are mostly ready for users > 1, it's only
few tc actions struggle a bit.
We cannot check tc actions from pktgen, since they can be added
dynamically.
So I see three options:
1 get rid of burst hack for both RX and TX in pktgen (kills performance)
2 add unlikely(skb_shread) check to few tc actions
3 do nothing

I think 2 isn't that bad after all if properly documented with
"because pktgen is doing this hack for performance" ?

I'm fine with 3 too, since the whole pktgen business is for root
and for kernel hackers who suppose to know what they're doing.