On Saturday, December 2, 2023 10:16 PM, Willem de Bruijn wrote: >Jesper Dangaard Brouer wrote: >> >> >> On 12/1/23 16:09, Willem de Bruijn wrote: >> > Song, Yoong Siang wrote: >> >> On Friday, December 1, 2023 6:46 PM, Jesper Dangaard Brouer ><hawk@xxxxxxxxxx> wrote: >> >>> On 12/1/23 07:24, Song Yoong Siang wrote: >> >>>> This series expands XDP TX metadata framework to include ETF HW offload. >> >>>> >> >>>> Changes since v1: >> >>>> - rename Time-Based Scheduling (TBS) to Earliest TxTime First (ETF) >> >>>> - rename launch-time to txtime >> >>>> >> >>> >> >>> I strongly disagree with this renaming (sorry to disagree with Willem). >> >>> >> >>> The i210 and i225 chips call this LaunchTime in their programmers >> >>> datasheets, and even in the driver code[1]. >> >>> >> >>> Using this "txtime" name in the code is also confusing, because how can >> >>> people reading the code know the difference between: >> >>> - tmo_request_timestamp and tmo_request_txtime >> >>> >> >> >> >> Hi Jesper and Willem, >> >> >> >> How about using "launch_time" for the flag/variable and >> >> "Earliest TxTime First" for the description/comments? >> > >> >> I don't follow why you are calling the feature: >> - "Earliest TxTime First" (ETF). >> - AFAIK this just reference an qdisc name (that most don't know exists) >> >> >> > I don't particularly care which term we use, as long as we're >> > consistent. Especially, don't keep introducing new synonyms. >> > >> > The fact that one happens to be one vendor's marketing term does not >> > make it preferable, IMHO. On the contrary. >> > >> >> These kind of hardware features are defined as part of Time Sensitive >> Networking (TSN). >> I believe these TSN features are defined as part of IEEE 802.1Qbv (2015) >> and according to Wikipedia[2] incorporated into IEEE 802.1Q. >> >> [2] https://en.wikipedia.org/wiki/Time-Sensitive_Networking >> >> >> > SO_TXTIME is in the ABI, and EDT has been used publicly in kernel >> > patches and conference talks, e.g., Van Jacobson's Netdev 0x12 >> > keynote. Those are vendor agnostic commonly used terms. >> > >> >> I agree that EDT (Earliest Departure Time) have become a thing and term >> in our community. >> We could associate this feature with this. >> I do fear what hardware behavior will be it if I e.g. ask it to send a >> packet 2 sec in the future on i225 which max support 1 sec. >> Will hardware send it at 1 sec? >> Because then I'm violating the *Earliest* Departure Time. > >That should definitely not happen. At least not on a device that >implements EDT semantics. > >This relates to Jakub's question in the previous thread on whether >this mechanism allows out-of-order transmission or maintains FIFO >behavior. That really is device specific. > >Older devices only support this for low rate (PTP) and with a small >fixed number of outstanding requests. For pacing offload, devices need >to support up to linerate and out-of-order. > >I don't think we want to enforce either in software, as the hardware >is already out there. But it would be good if drivers can somehow >label these capabilities. Including programmable horizon. > >It is up to the qdisc to ensure that it does not pass packets to the >device beyond its horizon. > >ETF and FQ already have a concept of horizon. And a way to queue >errors for packets out of bound (SO_EE_CODE_TXTIME_..). > >> >> > But as long as Launch Time is not an Intel only trademark, fine to >> > select that. >> >> The IEEE 802.1Qbv is sometimes called Time-Aware Shaper (TAS), but I >> don't like to for us to name this after this. This features is simply >> taking advantage of exposing one of the hardware building blocks >> (controlling/setting packet "launch time") that can be used for >> implementing a TAS. >> >> I like the name "launch time" because it doesn't get easily confused >> with other timestamps, and intuitively describes packet will be send at >> a specific time (likely in future). >> >> --Jesper > >Understood on your point that txtime and tx_timestamp are too similar. >As said, I don't care strongly. Launch time sounds fine to me. Others >can speak up if they disagree. > >I take launch time as a less strict than EDT: it is a request to send >at a certain time, with no strict definition on uncertainty. While EDT >more strictly ensures that a packet is not sent before the timestamp. Thanks for the deep discussion and information. I agree with launch time too. I will submit v3 with launch time so that others can review on the new naming and provide their feedback.
