Is it possible to call device layer code from driver code in Linux Kernel

Question

I am going through Linux Networking device driver code and wanted to know is it possible call device layer code from driver code.

--- a/drivers/net/ethernet/realtek/8139too.c
+++ b/drivers/net/ethernet/realtek/8139too.c
@@ -1706,10 +1706,20 @@ static netdev_tx_t rtl8139_start_xmit (struct sk_buff *skb,
    unsigned int entry;
    unsigned int len = skb->len;
     unsigned long flags;
-
+     int ret=0;
    /* Calculate the next Tx descriptor entry. */
    entry = tp->cur_tx % NUM_TX_DESC;

+
+        ret = dev_queue_xmit(skb);
+
+        if (likely(ret == NET_XMIT_SUCCESS || ret == NET_XMIT_CN)) {}
+
+         else {
+                dev->stats.tx_dropped++;
+
+        }
+

In above code ,I tried to call dev_queque_xmit(skb),which is an interface to device layer and it hooked up with Linux QoS code.

I made these changes in hope that packet drop due to Linux traffic control is captured by ifconfig stats under tx drop byte field,But not sure these changes would work?

Is it possible to call device layer from driver layer in such a way I tried?

Strudel

dev_queue_xmit() routine exports by kernel for device drivers, I think that your code should work. – Submaxillary

Thanks Alexey for your comments,My doubt is, Packets dropped at higher layer are still can be captured in the lower layer of network stack ? – Strudel

@Amit Singh Tomar, captured with what? – Nikko

@Nikko what I meant was , number of drop packets(due to QoS) should be updated in ifconfig stats . – Strudel

Amit, check the diagram from linuxfoundation.org/collaborate/workgroups/networking/… - linuxfoundation.org/images/1/1c/… – Nikko

It should work. If it is a good idea is a completely different question... – Pontic

Answer 1

As for if this code could work correctly, I doubt so. This change would cause trouble, like:

    dev_queue_xmit()
        -> enqueue to QoS (I assume you mean Qdisc)     
            -> rtl8139_start_xmit()  
                 -> dev_queue_xmit()      # creating a loop

Currently, no way for "ifconfig" to get to know "number of drop packets(due to QoS)", because "ifconfig" read statistics from /proc/net/dev, and those statistics doesn't contain QoS statistics, but just NIC driver itself.

But you can get to know "number of drop packets(due to QoS)", in other way. In kernel source code, there is:

   rtnl_register(PF_UNSPEC, RTM_GETQDISC, tc_get_qdisc, tc_dump_qdisc, NULL);   # it fill "gnet_stats_queue", and there is a drop counter internally.

which is to dump Qdisc status, including drop number due to congestion. It is a interface for Advanced user-level admin tool ( not "ifconfig" ) to retrieve more detailed information via rtlink message, in addition of "/proc/net/dev". However, I am not sure what those advanced user-level admin tool are (not familar with them). Maybe "ip" command could ??

Northeastwards

Thanks @Northeastwards for your response. Yes ,I got the kernel panic with changes I mentoned in my question .Right fix would be in net/sched and the fucntion you mentoned shows the incremented counter in "tc" command output. – Strudel

@xzxzhao28 is there any way to use rtnl_register() in order to show Qos packet in "ifconfig" output? – Strudel

@Amit, there seems no easy way to do that except for modifying some code. rtnl_register() is a netlink callback in kernel, and "tc" command use netlink socket to retrieve that information. But "ifconfig" read /proc/net/dev entry to get its data. So 3 ways: #a. modify kernel to add the statistics into /proc/net/dev, so "ifconfig" could get it. #b. modify "ifconfig", to also use netlink socket like "tc" command. #c. write a script utility to integrate "ifconfig" and "tc" command output. I guess #c is prefered, cauz no need to modify kernel or "ifconfig" internal . – Northeastwards

@xzha28 in late March given patch has provided to support this feature in linux kernel,git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/… – Strudel