netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.)

  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).