{"id":814802,"url":"http://patchwork.ozlabs.org/api/covers/814802/?format=json","web_url":"http://patchwork.ozlabs.org/project/netdev/cover/cover.1505719061.git.rcochran@linutronix.de/","project":{"id":7,"url":"http://patchwork.ozlabs.org/api/projects/7/?format=json","name":"Linux network development","link_name":"netdev","list_id":"netdev.vger.kernel.org","list_email":"netdev@vger.kernel.org","web_url":null,"scm_url":null,"webscm_url":null,"list_archive_url":"","list_archive_url_format":"","commit_url_format":""},"msgid":"","list_archive_url":null,"date":"2017-09-18T07:41:15","name":"[RFC,V1,net-next,0/6] Time based packet transmission","submitter":{"id":69550,"url":"http://patchwork.ozlabs.org/api/people/69550/?format=json","name":"Richard Cochran","email":"rcochran@linutronix.de"},"mbox":"http://patchwork.ozlabs.org/project/netdev/cover/cover.1505719061.git.rcochran@linutronix.de/mbox/","series":[{"id":3574,"url":"http://patchwork.ozlabs.org/api/series/3574/?format=json","web_url":"http://patchwork.ozlabs.org/project/netdev/list/?series=3574","date":"2017-09-18T07:41:16","name":"Time based packet transmission","version":1,"mbox":"http://patchwork.ozlabs.org/series/3574/mbox/"}],"comments":"http://patchwork.ozlabs.org/api/covers/814802/comments/","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xwdLr6wvDz9s3w\n\tfor ;\n\tMon, 18 Sep 2017 17:44:36 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752706AbdIRHoY (ORCPT );\n\tMon, 18 Sep 2017 03:44:24 -0400","from Galois.linutronix.de ([146.0.238.70]:49795 \"EHLO\n\tGalois.linutronix.de\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752519AbdIRHnZ (ORCPT\n\t); Mon, 18 Sep 2017 03:43:25 -0400","from rcochran by Galois.linutronix.de with local (Exim 4.80)\n\t(envelope-from )\n\tid 1dtqgD-0006bH-3S; Mon, 18 Sep 2017 09:41:21 +0200"],"From":"Richard Cochran ","To":"","Cc":", intel-wired-lan@lists.osuosl.org,\n\tAndre Guedes ,\n\tAnna-Maria Gleixner ,\n\tDavid Miller , Henrik Austad ,\n\tJesus Sanchez-Palencia ,\n\tJohn Stultz ,\n\tThomas Gleixner ,\n\tVinicius Costa Gomes ","Subject":"[PATCH RFC V1 net-next 0/6] Time based packet transmission","Date":"Mon, 18 Sep 2017 09:41:15 +0200","Message-Id":"","X-Mailer":"git-send-email 1.7.10.4","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"},"content":"This series is an early RFC that introduces a new socket option\nallowing time based transmission of packets. This option will be\nuseful in implementing various real time protocols over Ethernet,\nincluding but not limited to P802.1Qbv, which is currently finding\nits way into 802.1Q.\n\n* Open questions about SO_TXTIME semantics\n\n - What should the kernel do if the dialed Tx time is in the past?\n Should the packet be sent ASAP, or should we throw an error?\n\n - Should the kernel inform the user if it detects a missed deadline,\n via the error queue for example?\n\n - What should the timescale be for the dialed Tx time? Should the\n kernel select UTC when using the SW Qdisc and the HW time\n otherwise? Or should the socket option include a clockid_t?\n\n* Things todo\n\n - Design a Qdisc for purpose of configuring SO_TXTIME. There should\n be one option to dial HW offloading or SW best effort.\n\n - Implement the SW best effort variant. Here is my back of the\n napkin sketch. Each interface has its own timerqueue keeping the\n TXTIME packets in order and a FIFO for all other traffic. A guard\n window starts at the earliest deadline minus the maximum MTU minus\n a configurable fudge factor. The Qdisc uses a hrtimer to transmit\n the next packet in the timerqueue. During the guard window, all\n other traffic is defered unless the next packet can be transmitted\n before the guard window expires.\n\n* Current limitations\n\n - The driver does not handle out of order packets. If user space\n sends a packet with an earlier Tx time, then the code should stop\n the queue, reshuffle the descriptors accordingly, and then\n restart the queue.\n\n - The driver does not correctly queue up packets in the distant\n future. The i210 has a limited time window of +/- 0.5 seconds.\n Packets with a Tx time greater than that should be deferred in\n order to enqueue them later on.\n\n* Performance measurements\n\n 1. Prepared a PC and the Device Under Test (DUT) each with an Intel\n i210 card connected with a crossover cable.\n 2. The DUT was a Pentium(R) D CPU 2.80GHz running PREEMPT_RT\n 4.9.40-rt30 with about 50 usec maximum latency under cyclictest.\n 3. Synchronized the DUT's PHC to the PC's PHC using ptp4l.\n 4. Synchronized the DUT's system clock to its PHC using phc2sys.\n 5. Started netperf to produce some network load.\n 6. Measured the arrival time of the packets at the PC's PHC using\n hardware time stamping.\n\n I ran ten minute tests both with and without using the so_txtime\n option, with a period was 1 millisecond. I then repeated the\n so_txtime case but with a 250 microsecond period. The measured\n offset from the expected period (in nanoseconds) is shown in the\n following table.\n\n | | plain preempt_rt | so_txtime | txtime @ 250 us |\n |---------+------------------+---------------+-----------------|\n | min: | +1.940800e+04 | +4.720000e+02 | +4.720000e+02 |\n | max: | +7.556000e+04 | +5.680000e+02 | +5.760000e+02 |\n | pk-pk: | +5.615200e+04 | +9.600000e+01 | +1.040000e+02 |\n | mean: | +3.292776e+04 | +5.072274e+02 | +5.073602e+02 |\n | stddev: | +6.514709e+03 | +1.310849e+01 | +1.507144e+01 |\n | count: | 600000 | 600000 | 2400000 |\n\n Using so_txtime, the peak to peak jitter is about 100 nanoseconds,\n independent of the period. In contrast, plain preempt_rt shows a\n jitter of of 56 microseconds. The average delay of 507 nanoseconds\n when using so_txtime is explained by the documented input and output\n delays on the i210 cards.\n\n The test program is appended, below. If anyone is interested in\n reproducing this test, I can provide helper scripts.\n\nThanks,\nRichard\n\n\nRichard Cochran (6):\n net: Add a new socket option for a future transmit time.\n net: skbuff: Add a field to support time based transmission.\n net: ipv4: raw: Hook into time based transmission.\n net: ipv4: udp: Hook into time based transmission.\n net: packet: Hook into time based transmission.\n net: igb: Implement time based transmission.\n\n arch/alpha/include/uapi/asm/socket.h | 3 ++\n arch/frv/include/uapi/asm/socket.h | 3 ++\n arch/ia64/include/uapi/asm/socket.h | 3 ++\n arch/m32r/include/uapi/asm/socket.h | 3 ++\n arch/mips/include/uapi/asm/socket.h | 3 ++\n arch/mn10300/include/uapi/asm/socket.h | 3 ++\n arch/parisc/include/uapi/asm/socket.h | 3 ++\n arch/powerpc/include/uapi/asm/socket.h | 3 ++\n arch/s390/include/uapi/asm/socket.h | 3 ++\n arch/sparc/include/uapi/asm/socket.h | 3 ++\n arch/xtensa/include/uapi/asm/socket.h | 3 ++\n drivers/net/ethernet/intel/igb/e1000_82575.h | 1 +\n drivers/net/ethernet/intel/igb/e1000_defines.h | 68 +++++++++++++++++++++++++-\n drivers/net/ethernet/intel/igb/e1000_regs.h | 5 ++\n drivers/net/ethernet/intel/igb/igb.h | 3 +-\n drivers/net/ethernet/intel/igb/igb_main.c | 68 +++++++++++++++++++++++---\n include/linux/skbuff.h | 2 +\n include/net/sock.h | 2 +\n include/uapi/asm-generic/socket.h | 3 ++\n net/core/sock.c | 12 +++++\n net/ipv4/raw.c | 2 +\n net/ipv4/udp.c | 5 +-\n net/packet/af_packet.c | 6 +++\n 23 files changed, 200 insertions(+), 10 deletions(-)"}