From: Xie He <xie.he.0141@gmail.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
Network Development <netdev@vger.kernel.org>,
syzbot <syzbot+4a2c52677a8a1aa283cb@syzkaller.appspotmail.com>,
William Tu <u9012063@gmail.com>
Subject: Re: [Patch net] ip_gre: set dev->hard_header_len properly
Date: Sat, 10 Oct 2020 20:55:41 -0700 [thread overview]
Message-ID: <CAJht_EMo4bpzv_T0G5xx6t=dr4HgyTPHtk+m_NyMqEmAD5uo3A@mail.gmail.com> (raw)
In-Reply-To: <CAJht_EPQ8OXUeRxn7Q2AU9NsEuFB14Vs8Q0xBs-j9ka36RUVWQ@mail.gmail.com>
On Sat, Oct 10, 2020 at 2:49 PM Xie He <xie.he.0141@gmail.com> wrote:
>
> Another reason why tunnel devices usually don't provide
> header_ops->create might be to keep consistency with TAP devices. TAP
> devices are just like tunnel (TUN) devices except that they use an
> additional Ethernet header after the tunnel headers. I guess that TAP
> devices would usually use Ethernet's header_ops to expose only the
> Ethernet header to the user, but hide the outer tunnel headers from
> the user and let them be constructed on the transmission path (so that
> TAP devices would appear exactly like Ethernet devices). If we want to
> keep TUN devices consistent with TAP devices, we should hide the
> tunnel headers from the user for TUN devices, too.
Actually there's a "Universal TUN/TAP driver" in the kernel, which
passes L3 packets or Ethernet frames (that are being sent) back to the
user space and lets a user space program add the tunnel headers.
https://www.kernel.org/doc/Documentation/networking/tuntap.rst
In this case, we are not able to construct the tunnel headers until we
pass the packets / Ethernet frames back to the user space to the user
space program. We can only hide the tunnel headers.
To keep other TUN/TAP devices in the kernel consistent with the
"Universal TUN/TAP driver", we should hide the tunnel headers from the
user for those devices, too.
> Actually, a lot of devices expose a fake L2 header in header_ops,
> instead of their real L2 header anyway. Wi-Fi devices usually pretend
> to be Ethernet devices and expose an Ethernet header in header_ops. So
> I think it is acceptable to not expose the real L2 header in
> header_ops. (This is also what needed_headroom is created for - to
> request additional header space for headers not exposed in
> header_ops.)
next prev parent reply other threads:[~2020-10-11 3:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 1:21 [Patch net] ip_gre: set dev->hard_header_len properly Cong Wang
2020-10-08 11:48 ` Willem de Bruijn
2020-10-08 17:33 ` Cong Wang
2020-10-08 19:04 ` Willem de Bruijn
2020-10-08 19:16 ` Xie He
2020-10-08 19:19 ` Willem de Bruijn
2020-10-08 20:10 ` Xie He
2020-10-08 20:31 ` Willem de Bruijn
2020-10-08 21:35 ` Xie He
2020-10-08 21:47 ` Willem de Bruijn
2020-10-08 21:54 ` Xie He
2020-10-08 23:40 ` Xie He
2020-10-09 17:43 ` Cong Wang
2020-10-09 19:41 ` Xie He
2020-10-09 19:51 ` Xie He
2020-10-09 20:38 ` Cong Wang
2020-10-10 1:07 ` Cong Wang
2020-10-10 3:10 ` Xie He
2020-10-10 18:58 ` Cong Wang
2020-10-10 21:49 ` Xie He
2020-10-11 3:55 ` Xie He [this message]
2020-10-11 14:35 ` Xie He
2020-10-08 19:18 ` Willem de Bruijn
2020-10-08 19:50 ` Cong Wang
2020-10-08 20:19 ` Willem de Bruijn
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='CAJht_EMo4bpzv_T0G5xx6t=dr4HgyTPHtk+m_NyMqEmAD5uo3A@mail.gmail.com' \
--to=xie.he.0141@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=syzbot+4a2c52677a8a1aa283cb@syzkaller.appspotmail.com \
--cc=u9012063@gmail.com \
--cc=willemdebruijn.kernel@gmail.com \
--cc=xiyou.wangcong@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).