On 9/11/23 8:52 PM, Stanislav Fomichev wrote:
On 09/11, Daniel Borkmann wrote:
On 9/11/23 7:41 PM, Stanislav Fomichev wrote:
On 09/11, Daniel Borkmann wrote:
On 9/11/23 7:11 PM, Stanislav Fomichev wrote:
On 09/09, Martin KaFai Lau wrote:
On 9/8/23 2:00 PM, Stanislav Fomichev wrote:
[...]
I think my preference would be to just document it in the helper UAPI, what
Stan was suggesting below:
| Note, this is technically breaking existing UAPI where we used to
| return 1 and now will do -ENOBUFS. The alternative is to
| document that bpf_clone_redirect can return 1 for DROP and 2 for CN.
And then only adjusting the test case.
In this case, would we also need something similar to our
TCP_BPF_<state> changes? Like BUILD_BUG_ON(BPF_NET_XMIT_XXX !=
NET_XMIT_XXX)? Otherwise, we risk more leakage into the UAPI.
Merely documenting doesn't seem enough?
We could probably just mention that a positive, non-zero code indicates
that the skb clone got forwarded to the target netdevice but got dropped
from driver side. This is somewhat also driver dependent e.g. if you look
at dummy which does drop-all, it returns NETDEV_TX_OK. Anything more
specific in the helper doc such as defining BPF_NET_XMIT_* would be more
confusing.
Something like the following?
Return
0 on success, or a negative error in case of failure. Positive
error indicates a potential drop or congestion in the target
device. The particular positive error codes are not defined.
yeap, sgtm
