All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Aring <aar@pengutronix.de>
To: Network Development <netdev@vger.kernel.org>
Cc: Jukka Rissanen <jukka.rissanen@linux.intel.com>,
	Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	"linux-wpan@vger.kernel.org" <linux-wpan@vger.kernel.org>,
	Linux Bluetooth <linux-bluetooth@vger.kernel.org>
Subject: bluetooth 6lowpan interfaces are not virtual anymore
Date: Mon, 17 Apr 2017 19:56:12 +0200	[thread overview]
Message-ID: <2d178eb8-3fbc-3385-6e0c-fa9941713959@pengutronix.de> (raw)

Hi,

bluetooth-next contains patches which introduces a queue for bluetooth
6LoWPAN interfaces. [0]

At first, the current behaviour is now that 802.15.4 6LoWPAN interfaces
are virtual and bluetooth 6LoWPAN interfaces are not virtual anymore.
To have a different handling in both subsystems is _definitely_ wrong.

What does the 6LoWPAN interface?

It will do a protocol change (an adaptation, because 6LoWPAN should
provide the same functionality as IPv6) from IPv6 to 6LoWPAN (tx) and
vice versa for (rx). In my opinion this should be handled as a virtual
interface and not as an interface with a queue.

What makes a queue on 6LoWPAN interfaces?

It will queue IPv6 packets which waits for it adaptation (the protocol
change) with some additional qdisc handling.
If finally the xmit_do callback will occur it will replace IPv6 header
with 6LoWPAN, etc. After that it should be queued into some queue on
link layer side which should be do the transmit finally.

Why I think bluetooth introduced a queue handling on 6LoWPAN interfaces?

Because I think they don't like their own *qdisc* handling on their link
layer interface. I write *qdisc* here because, they have no net_devices
and use some kind of own qdisc handling.

My question: is this correct?

How to fix that (In my opinion):

So commit [0] says something "out of credits" that's what I think it's
the *qdisc* handling. If you cannot queue anymore -> you need to drop
it. If you don't like how the current behaviour is, you need to change
your *qdisc* handling on your link layer interface. Introducing queue at
6LoWPAN interfaces will introduce "buffer bloating".

---

I don't care what bluetooth does with the 6LoWPAN interface. If bluetooth
people wants such behaviour, then I am okay with that.

I will bookmark this mail for the time when somebody reverts it to a
virtual interface again. I think somebody will change it again, or maybe
somebody will argument why we need a queue here. 

- Alex

[0] https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=814f1b243d2c63928f6aa72d66bec0e5fae2f4a9

             reply	other threads:[~2017-04-17 17:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-17 17:56 Alexander Aring [this message]
     [not found] ` <2d178eb8-3fbc-3385-6e0c-fa9941713959-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2017-04-18 10:43   ` bluetooth 6lowpan interfaces are not virtual anymore Luiz Augusto von Dentz
2017-04-18 10:43     ` Luiz Augusto von Dentz
2017-04-18 10:43     ` Luiz Augusto von Dentz
     [not found]     ` <CABBYNZLqTvd5cnG4fKJgPKJGvS6hsk8vOM+7NQ_RhLJ-WOszmg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-19 17:43       ` Alexander Aring
2017-04-19 17:43         ` Alexander Aring
2017-04-24 10:35         ` Luiz Augusto von Dentz
     [not found]           ` <CABBYNZJqChBfB4jNCN3edmKSfhNd-haTKOjeYy1toK-Mn=qzoA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-26 15:05             ` Michael Richardson
2017-04-26 15:05               ` Michael Richardson
2017-04-26 15:05               ` Michael Richardson
2017-04-18 16:59 ` Michael Richardson
2017-04-18 16:59   ` Michael Richardson
2017-04-18 16:59   ` Michael Richardson
     [not found]   ` <28530.1492534783-FKvY79KaN4jY2Mpo3neBCSwD8/FfD2ys@public.gmane.org>
2017-04-19 18:01     ` Alexander Aring
2017-04-19 18:01       ` Alexander Aring
2017-04-26 14:55       ` Michael Richardson
2017-04-26 14:55         ` Michael Richardson
2017-04-26 14:55         ` Michael Richardson
     [not found]         ` <383.1493218546-VaGMqW6d0iXFptTlUKWvmrDks+cytr/Z@public.gmane.org>
2017-04-26 16:52           ` Jukka Rissanen
2017-04-26 16:52             ` Jukka Rissanen

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=2d178eb8-3fbc-3385-6e0c-fa9941713959@pengutronix.de \
    --to=aar@pengutronix.de \
    --cc=jukka.rissanen@linux.intel.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-wpan@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.