All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tariq Toukan <ttoukan.linux@gmail.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>, bpf@vger.kernel.org
Cc: netdev@vger.kernel.org, Stanislav Fomichev <sdf@google.com>,
	martin.lau@kernel.org, ast@kernel.org, daniel@iogearbox.net,
	alexandr.lobakin@intel.com, larysa.zaremba@intel.com,
	xdp-hints@xdp-project.net, anthony.l.nguyen@intel.com,
	yoong.siang.song@intel.com, boon.leong.ong@intel.com,
	intel-wired-lan@lists.osuosl.org, pabeni@redhat.com,
	jesse.brandeburg@intel.com, kuba@kernel.org, edumazet@google.com,
	john.fastabend@gmail.com, hawk@kernel.org, davem@davemloft.net
Subject: Re: [PATCH bpf V2] xdp: bpf_xdp_metadata use EOPNOTSUPP for no driver support
Date: Tue, 21 Mar 2023 22:43:31 +0200	[thread overview]
Message-ID: <682a413b-4f84-cc06-d378-3b44d721c64e@gmail.com> (raw)
In-Reply-To: <167940675120.2718408.8176058626864184420.stgit@firesoul>



On 21/03/2023 15:52, Jesper Dangaard Brouer wrote:
> When driver doesn't implement a bpf_xdp_metadata kfunc the fallback
> implementation returns EOPNOTSUPP, which indicate device driver doesn't
> implement this kfunc.
> 
> Currently many drivers also return EOPNOTSUPP when the hint isn't
> available, which is ambiguous from an API point of view. Instead
> change drivers to return ENODATA in these cases.
> 
> There can be natural cases why a driver doesn't provide any hardware
> info for a specific hint, even on a frame to frame basis (e.g. PTP).
> Lets keep these cases as separate return codes.
> 
> When describing the return values, adjust the function kernel-doc layout
> to get proper rendering for the return values.
> 
> Fixes: ab46182d0dcb ("net/mlx4_en: Support RX XDP metadata")
> Fixes: bc8d405b1ba9 ("net/mlx5e: Support RX XDP metadata")
> Fixes: 306531f0249f ("veth: Support RX XDP metadata")
> Fixes: 3d76a4d3d4e5 ("bpf: XDP metadata RX kfuncs")
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>

For the mlx4/5 parts:
Acked-by: Tariq Toukan <tariqt@nvidia.com>

Thanks!

WARNING: multiple messages have this Message-ID (diff)
From: Tariq Toukan <ttoukan.linux@gmail.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>, bpf@vger.kernel.org
Cc: xdp-hints@xdp-project.net, martin.lau@kernel.org,
	daniel@iogearbox.net, larysa.zaremba@intel.com,
	netdev@vger.kernel.org, john.fastabend@gmail.com, ast@kernel.org,
	jesse.brandeburg@intel.com, edumazet@google.com,
	pabeni@redhat.com, Stanislav Fomichev <sdf@google.com>,
	yoong.siang.song@intel.com, kuba@kernel.org,
	boon.leong.ong@intel.com, anthony.l.nguyen@intel.com,
	intel-wired-lan@lists.osuosl.org, davem@davemloft.net,
	hawk@kernel.org
Subject: Re: [Intel-wired-lan] [PATCH bpf V2] xdp: bpf_xdp_metadata use EOPNOTSUPP for no driver support
Date: Tue, 21 Mar 2023 22:43:31 +0200	[thread overview]
Message-ID: <682a413b-4f84-cc06-d378-3b44d721c64e@gmail.com> (raw)
In-Reply-To: <167940675120.2718408.8176058626864184420.stgit@firesoul>



On 21/03/2023 15:52, Jesper Dangaard Brouer wrote:
> When driver doesn't implement a bpf_xdp_metadata kfunc the fallback
> implementation returns EOPNOTSUPP, which indicate device driver doesn't
> implement this kfunc.
> 
> Currently many drivers also return EOPNOTSUPP when the hint isn't
> available, which is ambiguous from an API point of view. Instead
> change drivers to return ENODATA in these cases.
> 
> There can be natural cases why a driver doesn't provide any hardware
> info for a specific hint, even on a frame to frame basis (e.g. PTP).
> Lets keep these cases as separate return codes.
> 
> When describing the return values, adjust the function kernel-doc layout
> to get proper rendering for the return values.
> 
> Fixes: ab46182d0dcb ("net/mlx4_en: Support RX XDP metadata")
> Fixes: bc8d405b1ba9 ("net/mlx5e: Support RX XDP metadata")
> Fixes: 306531f0249f ("veth: Support RX XDP metadata")
> Fixes: 3d76a4d3d4e5 ("bpf: XDP metadata RX kfuncs")
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>

For the mlx4/5 parts:
Acked-by: Tariq Toukan <tariqt@nvidia.com>

Thanks!
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

  parent reply	other threads:[~2023-03-21 20:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-21 13:52 [PATCH bpf V2] xdp: bpf_xdp_metadata use EOPNOTSUPP for no driver support Jesper Dangaard Brouer
2023-03-21 13:52 ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-03-21 18:41 ` Stanislav Fomichev
2023-03-21 18:41   ` [Intel-wired-lan] " Stanislav Fomichev
2023-03-21 19:20 ` [xdp-hints] " Toke Høiland-Jørgensen
2023-03-21 19:20   ` [Intel-wired-lan] " Toke Høiland-Jørgensen
2023-03-21 20:43 ` Tariq Toukan [this message]
2023-03-21 20:43   ` [Intel-wired-lan] " Tariq Toukan
2023-03-22 18:34   ` Alexei Starovoitov
2023-03-22 18:34     ` [Intel-wired-lan] " Alexei Starovoitov

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=682a413b-4f84-cc06-d378-3b44d721c64e@gmail.com \
    --to=ttoukan.linux@gmail.com \
    --cc=alexandr.lobakin@intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=ast@kernel.org \
    --cc=boon.leong.ong@intel.com \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hawk@kernel.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=larysa.zaremba@intel.com \
    --cc=martin.lau@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf@google.com \
    --cc=xdp-hints@xdp-project.net \
    --cc=yoong.siang.song@intel.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.