Both are a place to store packets until something is done with the packet such that is no longer needs to be stored.
On the input side, usually there's little need to queue packets unless the device can't logically process them as quickly as they are received.
At the interface level, hardware almost always is designed to accept a packet and save it. Once it has been saved, something else must decide what to do with the received packet, generally either discard it or logically forward it.
On the output side, it takes time to transmit the packet, so it's queued until tranmitted.
If you had a device with the same bandwidths in and out, the device will accept the packet on input interface and queue it. Some logical process will examine the packet in the input queue, decide to discard it or forward it to an output queue. The output interface will transmit the packet and remove it from the output queue. In this example, there wasn't any congestion.
If the output link had less bandwidth than the input link, back-to-back arrival of input packets will usually queue on the output side.
Port buffers are often the term used for queues used directly by port interfaces. I believe on Cisco equipment, they are often refered to as tx or rx rings. Usually don't support a large queue size except on the faster interfaces. You can modify, on some interfaces, the tx-ring size.
Software queues, since they are usually stored in RAM can be quite large. Common defaults for input queues, on Cisco routers, I believe to be about 75, and for output, about 40. Often both can be increased/decreased by the configuration. Believe a common Cisco software queue (logical) max is about 4K (packets).
Port buffers are queues maintained by the interface port's software and are often very limited in size. This because actual RAM used for port buffers might be tied to a card and/or other special hardware support that allows port to push/pull bits very quickly.
Software queues are queues maintained by the IOS. They would normally be stored in main RAM. They are used to build some kind of ordered list of packets waiting for some processing. One common usage is to hold packets in a queue waiting for a port buffer to accept them.
Since port buffer queues are designed for speed, they also tend to only support very simple queuing, such as FIFO.
Software queues, being managed by IOS, often can support much more complicated queuing. On routers, besides FIFO, you have CQ, PQ, WFQ, CBWFQ, etc., for output software queues.
On switches, since so much queuing is directly tied to the hardware, software queuing is much more limited. A switch's IOS might only use software queuing for control plane functions, e.g. sending pending syslog entries, etc., using a FIFO queue.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...