On Thu, Feb 10, 2022 at 11:12:38PM -0800, Martin KaFai Lau wrote: > skb->tstamp was first used as the (rcv) timestamp. > The major usage is to report it to the user (e.g. SO_TIMESTAMP). > > Later, skb->tstamp is also set as the (future) delivery_time (e.g. EDT in TCP) > during egress and used by the qdisc (e.g. sch_fq) to make decision on when > the skb can be passed to the dev. > > Currently, there is no way to tell skb->tstamp having the (rcv) timestamp > or the delivery_time, so it is always reset to 0 whenever forwarded > between egress and ingress. > > While it makes sense to always clear the (rcv) timestamp in skb->tstamp > to avoid confusing sch_fq that expects the delivery_time, it is a > performance issue [0] to clear the delivery_time if the skb finally > egress to a fq@phy-dev. For example, when forwarding from egress to > ingress and then finally back to egress: > > tcp-sender => veth@netns => veth@hostns => fq@eth0@hostns > ^ ^ > reset rest > > This patch adds one bit skb->mono_delivery_time to flag the skb->tstamp > is storing the mono delivery_time (EDT) instead of the (rcv) timestamp. > > The current use case is to keep the TCP mono delivery_time (EDT) and > to be used with sch_fq. A later patch will also allow tc-bpf@ingress > to read and change the mono delivery_time. Can you be more specific? How is the fq in the hostns even visible to container ns? More importantly, why the packets are always going out from container to eth0?
