| Message ID | 20240930092416.80830-3-kerneljasonxing@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | net-timestamp: add some trivial | expand |
Jason Xing wrote: > From: Jason Xing <kernelxing@tencent.com> > > Introduce a test for SOF_TIMESTAMPING_OPT_ID_TCP for TCP proto so > that we can get aware of whether using write_seq as an initial key > value works as expected. Does the test behave different with this flag set? > > Signed-off-by: Jason Xing <kernelxing@tencent.com> > --- > tools/testing/selftests/net/txtimestamp.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/tools/testing/selftests/net/txtimestamp.c b/tools/testing/selftests/net/txtimestamp.c > index d626f22f9550..5f5de79d0e51 100644 > --- a/tools/testing/selftests/net/txtimestamp.c > +++ b/tools/testing/selftests/net/txtimestamp.c > @@ -893,6 +893,12 @@ static void do_main(int family) > do_test(family, SOF_TIMESTAMPING_TX_SCHED | > SOF_TIMESTAMPING_TX_SOFTWARE | > SOF_TIMESTAMPING_TX_ACK); > + > + fprintf(stderr, "\ntest ENQ + SND + ACK with tcp tskey setting\n"); > + do_test(family, SOF_TIMESTAMPING_TX_SCHED | > + SOF_TIMESTAMPING_TX_SOFTWARE | > + SOF_TIMESTAMPING_TX_ACK | > + SOF_TIMESTAMPING_OPT_ID_TCP); > } > } > > -- > 2.37.3 >
On Mon, Sep 30, 2024 at 6:42 PM Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote: > > Jason Xing wrote: > > From: Jason Xing <kernelxing@tencent.com> > > > > Introduce a test for SOF_TIMESTAMPING_OPT_ID_TCP for TCP proto so > > that we can get aware of whether using write_seq as an initial key > > value works as expected. > > Does the test behave different with this flag set? > Sorry, my mistake, the last email is not open to the mailing list. So I copy that here. Not that much, only at the very beginning, this new test will use write_seq directly. I once thought and wondered if I need to setsockopt() when one or two sendmsg() are already done, then we check the behaviour of subsequent sendmsg() calls. Then I changed my mind because it's a bit complex. Do you think it's a good way to test? Thanks, Jason
Jason Xing wrote: > On Mon, Sep 30, 2024 at 6:42 PM Willem de Bruijn > <willemdebruijn.kernel@gmail.com> wrote: > > > > Jason Xing wrote: > > > From: Jason Xing <kernelxing@tencent.com> > > > > > > Introduce a test for SOF_TIMESTAMPING_OPT_ID_TCP for TCP proto so > > > that we can get aware of whether using write_seq as an initial key > > > value works as expected. > > > > Does the test behave different with this flag set? > > > > Sorry, my mistake, the last email is not open to the mailing list. So > I copy that here. > > Not that much, only at the very beginning, this new test will use > write_seq directly. The kernel will act differently. But the test does not detect this. > I once thought and wondered if I need to setsockopt() when one or two > sendmsg() are already done, then we check the behaviour of subsequent > sendmsg() calls. Then I changed my mind because it's a bit complex. Do > you think it's a good way to test? Packetdrill is more suitable for deterministically testing such subtle differences. I have a packetdrill test for OPT_ID with and without OPT_ID_TCP. It is not public yet. As part of upstreaming our packetdrill tests, this will eventually also be available.
On Mon, Sep 30, 2024 at 7:54 PM Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote: > > Jason Xing wrote: > > On Mon, Sep 30, 2024 at 6:42 PM Willem de Bruijn > > <willemdebruijn.kernel@gmail.com> wrote: > > > > > > Jason Xing wrote: > > > > From: Jason Xing <kernelxing@tencent.com> > > > > > > > > Introduce a test for SOF_TIMESTAMPING_OPT_ID_TCP for TCP proto so > > > > that we can get aware of whether using write_seq as an initial key > > > > value works as expected. > > > > > > Does the test behave different with this flag set? > > > > > > > Sorry, my mistake, the last email is not open to the mailing list. So > > I copy that here. > > > > Not that much, only at the very beginning, this new test will use > > write_seq directly. > > The kernel will act differently. But the test does not detect this. No, it will not cover this. > > > I once thought and wondered if I need to setsockopt() when one or two > > sendmsg() are already done, then we check the behaviour of subsequent > > sendmsg() calls. Then I changed my mind because it's a bit complex. Do > > you think it's a good way to test? > > Packetdrill is more suitable for deterministically testing such subtle > differences. > > I have a packetdrill test for OPT_ID with and without OPT_ID_TCP. It > is not public yet. As part of upstreaming our packetdrill tests, this > will eventually also be available. Good to hear that. Now I think I will drop this patch. Thanks, Jason
diff --git a/tools/testing/selftests/net/txtimestamp.c b/tools/testing/selftests/net/txtimestamp.c index d626f22f9550..5f5de79d0e51 100644 --- a/tools/testing/selftests/net/txtimestamp.c +++ b/tools/testing/selftests/net/txtimestamp.c @@ -893,6 +893,12 @@ static void do_main(int family) do_test(family, SOF_TIMESTAMPING_TX_SCHED | SOF_TIMESTAMPING_TX_SOFTWARE | SOF_TIMESTAMPING_TX_ACK); + + fprintf(stderr, "\ntest ENQ + SND + ACK with tcp tskey setting\n"); + do_test(family, SOF_TIMESTAMPING_TX_SCHED | + SOF_TIMESTAMPING_TX_SOFTWARE | + SOF_TIMESTAMPING_TX_ACK | + SOF_TIMESTAMPING_OPT_ID_TCP); } }