On 6/25/19 2:35 AM, Daniel Borkmann wrote:
>
> But wasn't the whole point of 9c4c325252c5 ("skbuff: preserve sock reference
> when
> scrubbing the skb.") to defer orphaning to as late as possible? If I'm not
> missing
> anything, then above would reintroduce the issues that 9c4c325252c5 was
> trying to
> solve wrt TSQ/XPS/etc when skb was sent via veth based data path to cross
> netns and
> then forwarded to phys dev for transmission; meaning, skb->sk is lost at the
> point
> of dev_queue_xmit() for the latter. A side-effect this would also have is
> that this
> changes behavior again for tc egress programs sitting on phys dev (e.g.
> querying
> sock cookie or other related features).
Unless we can detect/decide that a packet going through veth pair is going to
be locally
consumed, or forwarded to a physical device (another ndo_start_xmit()), we need
to skb_orphan() the packet, exactly the same way than loopback ndo_start_xmit()
(We could have setups where these packets going through lo interface could be
forwarded
to a NIC...)
Backpressure is a best effort, we should not make it an absolute requirement and
prevent doing early demux as early as possible in RX path.
