On 2/5/2025 11:16 PM, Ido Schimmel wrote:
On Tue, Feb 04, 2025 at 11: 25: 39PM +0530, Malladi, Meghana wrote: > On
1/23/2025 10: 55 PM, Ido Schimmel wrote: > > XDP program could have
changed the packet length, but driver seems to be > > This will be true
given, emac->xdp_prog
ZjQcmQRYFpfptBannerStart
This message was sent from outside of Texas Instruments.
Do not click links or open attachments unless you recognize the source
of this email and know the content is safe.
Report Suspicious
<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK!
v9dnXdhkNoe0hkqlFZKoUhMAqXZwolk5zXhypw1qeZY8pxUHTuuleZBOKulyBnK9eA$>
ZjQcmQRYFpfptBannerEnd
On Tue, Feb 04, 2025 at 11:25:39PM +0530, Malladi, Meghana wrote:
On 1/23/2025 10:55 PM, Ido Schimmel wrote:
> XDP program could have changed the packet length, but driver seems to be
This will be true given, emac->xdp_prog is not NULL. What about when XDP is
not enabled ?
I don't understand the question. My point is that the packet doesn't
necessarily look the same after XDP ran.
emac_rx_packet() is a common function for both XDP and non-XDP use
cases. XDP will only run when emac->xdp_prog is not NULL. I understand
that when XDP ran, it can change the contents of the packet hence it is
advisable to use "xdp_build_skb_from_buff(const struct xdp_buff *xdp)",
but for cases when xdp doesn't run - the xdp struct has junk/zero value
which cannot be converted into some valid skb. But I think I will do
something like this:
if (emac->xdp_prog)
xdp_build_skb_from_buff(xdp);
else
skb = napi_build_skb(pa, PAGE_SIZE);
Hope this will address your comment.
> building the skb using original length read from the descriptor.
> Consider using xdp_build_skb_from_buff()
>
