Interface hold-queue software or hardware queue option ?

[from88]

Hello, cant find more informaton about hold-queue under interface.

My question would be about hold-queue interface command. Do it changes the hardware or the software queue size ? Thanks.

[Mark Malone]

The hold-queue parameter per interface governs the amount of buffer that the physical interface can use

This may help explains how it works

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/quality-of-service-qos/sol_ov_c22-708224.html

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Usually hold-queue adjusts the interface's software FIFO queue.

The interface's hardware FIFO queue might be adjusted using tx-ring-limit.

[from88]

hmm, both answers a little bit counters each other:)

so, if's a software queue, can we say, that it's "activated" only when the interface is utilized 100%. ? Since qos only starts to work then the utilization on interface reaches high utilization..

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

hmm, both answers a little bit counters each other:)

Why do you think that?

Mark referenced HQF, so I tried to focus on your specific question as you asked about an interface's hold-queue statement (as generally found on many Cisco routers).

so, if's a software queue, can we say, that it's "activated" only when the interface is utilized 100%. ? Since qos only starts to work then the utilization on interface reaches high utilization..

Depends on what kind of software queue we're discussing (and device's hardware architecture).

For example, shaping queues generally queue traffic before an interface is utilized 100%

WRED acts upon packets based on past history of utilization.  It normally lags current utilization.

Policers act on their own settings, which can differ from physical interface utilization.

However, if what you have in mind is typical router interface egress FIFO queuing, packets waiting to be transmitted are queued somewhere or they're dropped.  Often a router interface has a "special" FIFO egress queue that the interface transmits from, the tx-ring.

One might think the tx-ring is always populated from a software queues, but on some devices and interfaces, packets seem to first start with the tx-ring (this appears to be to insure optimal packet forwarding).

[from88]

Thanks!

Just think that software queue is separate than the buffer of the physical interface. Or do they share the same amount of 'depth' ?

By the way: for example i use just CBWFQ for some classes. So for example it will not take effect unless I utilize the interface ?

If yes: what utilization should be - by bandwidth? or by queue? btw: theoretical question: do it's possible to "overqueue" the interface without utilizing it by bandwidth ?

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Just think that software queue is separate than the buffer of the physical interface. Or do they share the same amount of 'depth' ?

They are logically separate and probably have different depths.

By the way: for example i use just CBWFQ for some classes. So for example it will not take effect unless I utilize the interface ?

Yes, you need to tie a CBWFQ policy to an interface, and as it operates on interface traffic, that would be some interface utilization.

If yes: what utilization should be - by bandwidth? or by queue?

Depends on the nature of the policy and what you're trying to accomplish.

btw: theoretical question: do it's possible to "overqueue" the interface without utilizing it by bandwidth ?

Sorry, don't understand what you mean by over queue.

[from88]

Thanks for answers.

The software queue takes places when the HQ tx-ring is fully congested, Right ?

I want to clarify how the interface should be congested to activate the software queue.

a) Congested by the interface bandwidth utilization or b) Congested by the tx-ring  QUEUE Utilization ?

When the interface is congested by bandwidth usage do it's also at the same time the interface tx-ring queue should be congested  ?

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

The software queue takes places when the HQ tx-ring is fully congested, Right ?

As noted in an earlier post: "Depends on what kind of software queue we're discussing (and device's hardware architecture)."

I want to clarify how the interface should be congested to activate the software queue.

a) Congested by the interface bandwidth utilization or b) Congested by the tx-ring  QUEUE Utilization ?

When the interface is congested by bandwidth usage do it's also at the same time the interface tx-ring queue should be congested  ?

Again, "Depends on what kind of software queue we're discussing (and device's hardware architecture)."

A "congested interface" is one or more packets (or frames) are waiting to be transmitted. However, such congestion can vary much in time duration.  For example, consider a device with an FE ingress interface and a serial T1 egress interface.  If the FE accepts two packets, back-to-back.  The 2nd packet must wait on the T1 interface during the 1st packet's transmission.  During that wait, the interface is "congested".  But, if there were only just those two packets, transmitted over an hour, would you consider the interface congested?  Probably not, yet for the purpose of queuing, it had to queue or drop the 2nd FE interface received packet because the T1 interface cannot transmit the packets as quickly as received by the FE interface.

In the prior example, where would the 2nd received packet be queued?  That's an "it depends" answer.  It might be queued in the T1 interface's tx-ring.

If instead of 2 packets, 2000 packets were received, again back-to-back, they might all be queued in the tx-ring buffer, but if the buffer cannot hold all of them, what happens?  Perhaps the "overflow" is queued in the interface hold-queue (out).