[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAA93jw6d7kCNruJ9RcXb8fJoysrH3Qfr=mrevf_XanVUXorvSg@mail.gmail.com>
Date: Wed, 18 Jul 2018 11:40:01 -0700
From: Dave Taht <dave.taht@...il.com>
To: jesus.sanchez-palencia@...el.com
Cc: Eric Dumazet <eric.dumazet@...il.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
tglx@...utronix.de, jan.altenberg@...utronix.de,
vinicius.gomes@...el.com, kurt.kanzenbach@...utronix.de,
henrik@...tad.us, richardcochran@...il.com,
ilias.apalodimas@...aro.org, ivan.khoronzhuk@...aro.org,
mlichvar@...hat.com, willemb@...gle.com,
Jamal Hadi Salim <jhs@...atatu.com>,
Cong Wang <xiyou.wangcong@...il.com>,
Jiří Pírko <jiri@...nulli.us>,
Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Subject: Re: [PATCH v2 net-next 01/14] net: Clear skb->tstamp only on the
forwarding path
In my dreamworld, a packet with a timestamp achieved at rx time on
ethX, or via local traffic, would be consistent with the right clock
throughout the system and reliably still be there when it goes to
ethY.
This would save having to timestamp (again) inside the cb block in
fq_codel, cake, etc, and more importantly, measure total system delay
from entrance to egress, (e.g tc filters, firewall rules, routing
table lookups), not just queuing delay at the qdisc, thus detecting
when a system was overloaded and reducing queue size and throughput
appropriately as a result to cope.
Powered by blists - more mailing lists