From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Stanislav Fomichev <sdf@google.com>,
Lorenzo Bianconi <lorenzo@kernel.org>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, davem@davemloft.net,
kuba@kernel.org, hawk@kernel.org, pabeni@redhat.com,
edumazet@google.com, memxor@gmail.com, alardam@gmail.com,
saeedm@nvidia.com, anthony.l.nguyen@intel.com,
gospo@broadcom.com, vladimir.oltean@nxp.com, nbd@nbd.name,
john@phrozen.org, leon@kernel.org, simon.horman@corigine.com,
aelior@marvell.com, christophe.jaillet@wanadoo.fr,
ecree.xilinx@gmail.com, mst@redhat.com, bjorn@kernel.org,
magnus.karlsson@intel.com, maciej.fijalkowski@intel.com,
intel-wired-lan@lists.osuosl.org, lorenzo.bianconi@redhat.com,
martin.lau@linux.dev
Subject: Re: [PATCH v3 bpf-next 8/8] selftests/bpf: introduce XDP compliance test tool
Date: Fri, 27 Jan 2023 18:52:58 +0100 [thread overview]
Message-ID: <874jsblv9h.fsf@toke.dk> (raw)
In-Reply-To: <CAKH8qBv9wKzkW8Qk+hDKCmROKem6ajkqhF_KRqdEKWSLL6_HsA@mail.gmail.com>
Stanislav Fomichev <sdf@google.com> writes:
>> > > +
>> > > + ctrl_sockfd = accept(sockfd, (struct sockaddr *)&ctrl_addr, &len);
>> > > + if (ctrl_sockfd < 0) {
>> > > + fprintf(stderr, "Failed to accept connection on DUT socket\n");
>> > > + close(sockfd);
>> > > + return -errno;
>> > > + }
>> > > +
>>
>> [...]
>>
>> >
>> > There is also connect_to_fd, maybe we can use that? It should take
>> > care of the timeouts.. (requires plumbing server_fd, not sure whether
>> > it's a problem or not)
>>
>> please correct me if I am wrong, but in order to have server_fd it is mandatory
>> both tester and DUT are running on the same process, right? Here, I guess 99% of
>> the times DUT and tester will run on two separated devices. Agree?
>
> Yes, it's targeting more the case where you have a server fd and a
> bunch of clients in the same process. But I think it's still usable in
> your case, you're not using fork() anywhere afaict, so even if these
> are separate devices, connect_to_fd should still work. (unless I'm
> missing something, haven't looked too closely)
Just to add a bit of context here, "separate devices" can refer to the
hosts as well as the netdevs. I.e., it should also be possible to run
this in a mode where the client bit runs on a different physical machine
than the server bit (as it will not be feasible in any case to connect
things with loopback cables).
-Toke
WARNING: multiple messages have this Message-ID (diff)
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Stanislav Fomichev <sdf@google.com>,
Lorenzo Bianconi <lorenzo@kernel.org>
Cc: mst@redhat.com, vladimir.oltean@nxp.com, ast@kernel.org,
edumazet@google.com, anthony.l.nguyen@intel.com,
daniel@iogearbox.net, andrii@kernel.org,
intel-wired-lan@lists.osuosl.org, simon.horman@corigine.com,
kuba@kernel.org, pabeni@redhat.com, aelior@marvell.com,
hawk@kernel.org, christophe.jaillet@wanadoo.fr, memxor@gmail.com,
john@phrozen.org, bjorn@kernel.org, bpf@vger.kernel.org,
magnus.karlsson@intel.com, leon@kernel.org,
netdev@vger.kernel.org, martin.lau@linux.dev,
ecree.xilinx@gmail.com, alardam@gmail.com, gospo@broadcom.com,
saeedm@nvidia.com, davem@davemloft.net, nbd@nbd.name
Subject: Re: [Intel-wired-lan] [PATCH v3 bpf-next 8/8] selftests/bpf: introduce XDP compliance test tool
Date: Fri, 27 Jan 2023 18:52:58 +0100 [thread overview]
Message-ID: <874jsblv9h.fsf@toke.dk> (raw)
In-Reply-To: <CAKH8qBv9wKzkW8Qk+hDKCmROKem6ajkqhF_KRqdEKWSLL6_HsA@mail.gmail.com>
Stanislav Fomichev <sdf@google.com> writes:
>> > > +
>> > > + ctrl_sockfd = accept(sockfd, (struct sockaddr *)&ctrl_addr, &len);
>> > > + if (ctrl_sockfd < 0) {
>> > > + fprintf(stderr, "Failed to accept connection on DUT socket\n");
>> > > + close(sockfd);
>> > > + return -errno;
>> > > + }
>> > > +
>>
>> [...]
>>
>> >
>> > There is also connect_to_fd, maybe we can use that? It should take
>> > care of the timeouts.. (requires plumbing server_fd, not sure whether
>> > it's a problem or not)
>>
>> please correct me if I am wrong, but in order to have server_fd it is mandatory
>> both tester and DUT are running on the same process, right? Here, I guess 99% of
>> the times DUT and tester will run on two separated devices. Agree?
>
> Yes, it's targeting more the case where you have a server fd and a
> bunch of clients in the same process. But I think it's still usable in
> your case, you're not using fork() anywhere afaict, so even if these
> are separate devices, connect_to_fd should still work. (unless I'm
> missing something, haven't looked too closely)
Just to add a bit of context here, "separate devices" can refer to the
hosts as well as the netdevs. I.e., it should also be possible to run
this in a mode where the client bit runs on a different physical machine
than the server bit (as it will not be feasible in any case to connect
things with loopback cables).
-Toke
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
next prev parent reply other threads:[~2023-01-27 17:54 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-26 12:58 [PATCH v3 bpf-next 0/8] xdp: introduce xdp-feature support Lorenzo Bianconi
2023-01-26 12:58 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-26 12:58 ` [PATCH v3 bpf-next 1/8] netdev-genl: create a simple family for netdev stuff Lorenzo Bianconi
2023-01-26 12:58 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-26 12:58 ` [PATCH v3 bpf-next 2/8] drivers: net: turn on XDP features Lorenzo Bianconi
2023-01-26 12:58 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-26 18:27 ` sdf
2023-01-26 18:27 ` [Intel-wired-lan] " sdf
2023-01-26 12:58 ` [PATCH v3 bpf-next 3/8] xsk: add usage of XDP features flags Lorenzo Bianconi
2023-01-26 12:58 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-26 12:58 ` [PATCH v3 bpf-next 4/8] libbpf: add the capability to specify netlink proto in libbpf_netlink_send_recv Lorenzo Bianconi
2023-01-26 12:58 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-26 12:58 ` [PATCH v3 bpf-next 5/8] libbpf: add API to get XDP/XSK supported features Lorenzo Bianconi
2023-01-26 12:58 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-27 23:38 ` Andrii Nakryiko
2023-01-27 23:38 ` [Intel-wired-lan] " Andrii Nakryiko
2023-01-28 12:48 ` Lorenzo Bianconi
2023-01-28 12:48 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-26 12:58 ` [PATCH v3 bpf-next 6/8] bpf: devmap: check XDP features in __xdp_enqueue routine Lorenzo Bianconi
2023-01-26 12:58 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-26 12:58 ` [PATCH v3 bpf-next 7/8] selftests/bpf: add test for bpf_xdp_query xdp-features support Lorenzo Bianconi
2023-01-26 12:58 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-26 18:28 ` sdf
2023-01-26 18:28 ` [Intel-wired-lan] " sdf
2023-01-26 12:58 ` [PATCH v3 bpf-next 8/8] selftests/bpf: introduce XDP compliance test tool Lorenzo Bianconi
2023-01-26 12:58 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-26 18:36 ` sdf
2023-01-26 18:36 ` [Intel-wired-lan] " sdf
2023-01-27 8:19 ` Martin KaFai Lau
2023-01-27 8:19 ` [Intel-wired-lan] " Martin KaFai Lau
2023-01-27 17:26 ` Lorenzo Bianconi
2023-01-27 17:26 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-27 17:26 ` Lorenzo Bianconi
2023-01-27 17:26 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-27 17:41 ` Stanislav Fomichev
2023-01-27 17:41 ` [Intel-wired-lan] " Stanislav Fomichev
2023-01-27 17:52 ` Toke Høiland-Jørgensen [this message]
2023-01-27 17:52 ` Toke Høiland-Jørgensen
2023-01-27 17:58 ` Lorenzo Bianconi
2023-01-27 17:58 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-27 17:59 ` Stanislav Fomichev
2023-01-27 17:59 ` [Intel-wired-lan] " Stanislav Fomichev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874jsblv9h.fsf@toke.dk \
--to=toke@redhat.com \
--cc=aelior@marvell.com \
--cc=alardam@gmail.com \
--cc=andrii@kernel.org \
--cc=anthony.l.nguyen@intel.com \
--cc=ast@kernel.org \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=christophe.jaillet@wanadoo.fr \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=ecree.xilinx@gmail.com \
--cc=edumazet@google.com \
--cc=gospo@broadcom.com \
--cc=hawk@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=john@phrozen.org \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=lorenzo.bianconi@redhat.com \
--cc=lorenzo@kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=mst@redhat.com \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=sdf@google.com \
--cc=simon.horman@corigine.com \
--cc=vladimir.oltean@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.