From: ebiederm@xmission•com (Eric W. Biederman)
To: Jiri Benc <jbenc@redhat•com>
Cc: Thomas Graf <tgraf@suug•ch>,
netdev@vger•kernel.org, Roopa Prabhu <roopa@cumulusnetworks•com>
Subject: Re: [PATCH net 0/2] lwtunnel: make it really work, for IPv4
Date: Wed, 23 Sep 2015 12:42:30 -0500 [thread overview]
Message-ID: <8761313ud5.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20150923162927.6d437a1f@griffin> (Jiri Benc's message of "Wed, 23 Sep 2015 16:29:27 +0200")
Jiri Benc <jbenc@redhat•com> writes:
> On Wed, 23 Sep 2015 07:17:53 -0500, Eric W. Biederman wrote:
>> Assuming the transport is UDP then it would be a UDP socket. That
>> socket will have all of the information needed to construct the outer
>> header as the receive path of that socket removes the outer header.
>>
>> I admit you can't use the cached dst. It is the wrong on that socket.
>>
>> My point is that if we have the UDP socket and we have the sk we have
^skb
>> all of the information we need to compute the reverse dst.
>
> That (single) UDP socket may represent many tunnels with different
> parameters. Knowing the socket is still not enough to construct the
> data. The only place where the needed data is stored is routing table
> which won't help us much for ARP, and the metadata dst attached to the
> incoming skb.
Having read through the code a bit more. I understand more clearly what
is happening with metadata dsts.
Without your ARP changes in this patchset I don't understand what the
purpose of metadata dsts are, so I am probably still missing something
important.
If ARP and ndisc are the only uses of metadata dsts, allocating a
metadata dst for every packet seems undesirable.
In which case I suspect what is desriable is a ndo operation that
looks at the packet and computes the dst.
So perhaps instead of:
+ if (arp->ar_op == htons(ARPOP_REQUEST) && skb_metadata_dst(skb))
+ reply_dst = (struct dst_entry *)
+ iptunnel_metadata_reply(skb_metadata_dst(skb),
+ GFP_ATOMIC);
+
The code would be:
if (arp->ar_op == htons(AROP_REQUEST) && dev->ndo_reply_dst)
reply_dst = dev->ndo_reply_dst(skb, GFP_ATOMIC);
For any network that does interesting things with network level
identifiers below IP this seems like a general problem. Further it
seems more desirable to only perform an allocation when necessary,
rather than for every packet, and two for the packets that actually
need replies.
Eric
next prev parent reply other threads:[~2015-09-23 17:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 16:12 [PATCH net 0/2] lwtunnel: make it really work, for IPv4 Jiri Benc
2015-09-22 16:12 ` [PATCH net 1/2] ipv4: send arp replies to the correct tunnel Jiri Benc
2015-09-23 8:10 ` Thomas Graf
2015-09-22 16:12 ` [PATCH net 2/2] lwtunnel: remove source and destination UDP port config option Jiri Benc
2015-09-23 8:12 ` Thomas Graf
2015-09-23 4:39 ` [PATCH net 0/2] lwtunnel: make it really work, for IPv4 Eric W. Biederman
2015-09-23 8:09 ` Thomas Graf
2015-09-23 12:17 ` Eric W. Biederman
2015-09-23 14:29 ` Jiri Benc
2015-09-23 17:42 ` Eric W. Biederman [this message]
2015-09-23 20:54 ` Jiri Benc
2015-09-23 21:09 ` Eric W. Biederman
2015-09-23 23:08 ` Thomas Graf
2015-09-24 5:54 ` Eric W. Biederman
2015-09-24 8:19 ` Jiri Benc
2015-09-24 8:35 ` Jiri Benc
2015-09-23 8:08 ` Thomas Graf
2015-09-24 21:32 ` David Miller
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=8761313ud5.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission$(echo .)com \
--cc=jbenc@redhat$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=roopa@cumulusnetworks$(echo .)com \
--cc=tgraf@suug$(echo .)ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox