1

ip addr show output from within a Kubernetes pod

root@customer-fd99fb7dc-82hrr:/app# ip -c addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 8e:e3:d2:b5:d2:94 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.171.139/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::8ce3:d2ff:feb5:d294/64 scope link 
       valid_lft forever preferred_lft forever

etho0@1f6 is one end of the veth pair. This explains qdisc noqueue

My understanding of noqueue qdisc is that, it sends the network packet immediately (if it can) or would drop it otherwise. So, I assumed that noqueue is not backed by any queues. But, qlen 1000 is contradicting with my understanding.

Does it mean noqueue has an internal queue? Can I think of noqueue qdisc as pfifo_fast minus the 3 internal classes/bands?

1 Answer 1

2

qlen is the interface parameter set with ip link set eth0 txqueuelen 1000 or ifconfig eth0 txqueuelen 1000 (see ifconfig(8))

In the kernel it is called dev->tx_queue_len and defaults to DEFAULT_TX_QUEUE_LEN = 1000. This is what ip link ls shows.

When a queueing discipline is attached to a device it takes the the device qlen setting and uses that. When you replace the qdisc with another, it still uses the same qlen. Or ignores it, as noqueue qdisc does.

(disclaimer: not a kernel expert)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .