[PATCH] Add DEVICE_OPEN_FLAG_DATA_FORMAT

[Bjørn Mork]

Dan Williams <dcbw at redhat.com> writes:

> Bjorn: for the QoS stuff, I'd imagine if we get multi-interface devices,
> we'd be using the QoS headers to map into Linux SKB priorites during TX
> and RX.  That way, if a dedicated bearer is set up with different QoS
> values, we can actually follow that all the way through to the TCP/IP
> stack on the host side and maybe get some QoS for VOIP.

Could be, but we would need to understand how the firmware use these
headers for them to be useful.  The only free information I've been able
to dig up is the codeaurora rmnet_host driver (a pity that driver wasn't
available when I started out):

https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=blob;f=drivers/net/usb/rmnet_usb_data.c;hb=msm-3.4

It just copies the mark (which can be set by an iptables rule) from the
skb into the QoS header flow_id:

static struct sk_buff *rmnet_usb_tx_fixup(struct usbnet *dev,
		struct sk_buff *skb, gfp_t flags)
{
	struct QMI_QOS_HDR_S	*qmih;

	if (test_bit(RMNET_MODE_QOS, &dev->data[0])) {
		qmih = (struct QMI_QOS_HDR_S *)
		skb_push(skb, sizeof(struct QMI_QOS_HDR_S));
		qmih->version = 1;
		qmih->flags = 0;
		qmih->flow_id = skb->mark;
	 }

	DBG1("[%s] Tx packet #%lu len=%d mark=0x%x\n",
	    dev->net->name, dev->net->stats.tx_packets, skb->len, skb->mark);

	return skb;
}


But I soon found that high flow_id values would make the firmware crash,
so this approach is too simple.  There should most likely be some
filtering or mapping in the driver, maybe limiting the flow_id to the
max supported flows? Which is?  And what's with the flags?  How do we
use this to tell the device that we want strict priority for this flow?

I don't know these answers, and I am not going to guess.  This is
completely useless without any documentation.



Bjørn