* Getting at the UDP headers from ->data_ready()
@ 2016-04-11 21:04 David Howells
2016-04-11 21:18 ` Willem de Bruijn
0 siblings, 1 reply; 3+ messages in thread
From: David Howells @ 2016-04-11 21:04 UTC (permalink / raw)
To: willemb; +Cc: dhowells, netdev
Hi Willem,
With regards to:
commit 4d0fc73ebe94ac984a187f21fbf4f3a1ac846f5a
Author: Willem de Bruijn <willemb@google.com>
Date: Thu Apr 7 11:44:59 2016 -0400
rxrpc: do not pull udp headers on receive
Commit e6afc8ace6dd modified the udp receive path by pulling the udp
header before queuing an skbuff onto the receive queue.
Does that mean that I can no longer access the UDP header via udp_hdr(skb)
from with the ->data_ready() handler?
I'm guessing that's not actually the case since ip_hdr(skb) seems to work - or
is that something I shouldn't be using since the part of the buffer containing
the IP header might've been discarded?
David
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Getting at the UDP headers from ->data_ready()
2016-04-11 21:04 Getting at the UDP headers from ->data_ready() David Howells
@ 2016-04-11 21:18 ` Willem de Bruijn
2016-04-11 21:23 ` David Howells
0 siblings, 1 reply; 3+ messages in thread
From: Willem de Bruijn @ 2016-04-11 21:18 UTC (permalink / raw)
To: David Howells; +Cc: Willem de Bruijn, Network Development
On Mon, Apr 11, 2016 at 5:04 PM, David Howells <dhowells@redhat.com> wrote:
> Hi Willem,
>
> With regards to:
>
> commit 4d0fc73ebe94ac984a187f21fbf4f3a1ac846f5a
> Author: Willem de Bruijn <willemb@google.com>
> Date: Thu Apr 7 11:44:59 2016 -0400
>
> rxrpc: do not pull udp headers on receive
>
> Commit e6afc8ace6dd modified the udp receive path by pulling the udp
> header before queuing an skbuff onto the receive queue.
>
> Does that mean that I can no longer access the UDP header via udp_hdr(skb)
> from with the ->data_ready() handler?
>
> I'm guessing that's not actually the case since ip_hdr(skb) seems to work - or
> is that something I shouldn't be using since the part of the buffer containing
> the IP header might've been discarded?
The network and transport header pointers are still valid. Commit e6afc8ace6dd
only changes where skb->data points to. It does not discard the data between
skb->head and skb->data. This rxrpc follow-up patch fixes some offset
arithmetic to the payload, which is computed relative to skb->data.
There are other uses of ip_hdr and udp_hdr in udp_recvmsg and similar
recvmsg handlers for other protocols. For instance, in the source address
processing for recvfrom ("if (sin) { .. }")
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Getting at the UDP headers from ->data_ready()
2016-04-11 21:18 ` Willem de Bruijn
@ 2016-04-11 21:23 ` David Howells
0 siblings, 0 replies; 3+ messages in thread
From: David Howells @ 2016-04-11 21:23 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: dhowells, Willem de Bruijn, Network Development
Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote:
> The network and transport header pointers are still valid. Commit e6afc8ace6dd
> only changes where skb->data points to. It does not discard the data between
> skb->head and skb->data. This rxrpc follow-up patch fixes some offset
> arithmetic to the payload, which is computed relative to skb->data.
>
> There are other uses of ip_hdr and udp_hdr in udp_recvmsg and similar
> recvmsg handlers for other protocols. For instance, in the source address
> processing for recvfrom ("if (sin) { .. }")
Excellent, thanks!
David
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-04-11 21:23 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-11 21:04 Getting at the UDP headers from ->data_ready() David Howells
2016-04-11 21:18 ` Willem de Bruijn
2016-04-11 21:23 ` David Howells
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox