Message ID | 20200311173356.38181-1-petrm@mellanox.com |
---|---|
Headers | show |
Series | RED: Introduce an ECN tail-dropping mode | expand |
From: Petr Machata <petrm@mellanox.com> Date: Wed, 11 Mar 2020 19:33:50 +0200 > When the RED qdisc is currently configured to enable ECN, the RED algorithm > is used to decide whether a certain SKB should be marked. If that SKB is > not ECN-capable, it is early-dropped. > > It is also possible to keep all traffic in the queue, and just mark the > ECN-capable subset of it, as appropriate under the RED algorithm. Some > switches support this mode, and some installations make use of it. > There is currently no way to put the RED qdiscs to this mode. > > Therefore this patchset adds a new RED flag, TC_RED_TAILDROP. When the > qdisc is configured with this flag, non-ECT traffic is enqueued (and > tail-dropped when the queue size is exhausted) instead of being > early-dropped. ... Series applied, thank you.
David Miller <davem@davemloft.net> writes: > From: Petr Machata <petrm@mellanox.com> > Date: Wed, 11 Mar 2020 19:33:50 +0200 > >> When the RED qdisc is currently configured to enable ECN, the RED algorithm >> is used to decide whether a certain SKB should be marked. If that SKB is >> not ECN-capable, it is early-dropped. >> >> It is also possible to keep all traffic in the queue, and just mark the >> ECN-capable subset of it, as appropriate under the RED algorithm. Some >> switches support this mode, and some installations make use of it. >> There is currently no way to put the RED qdiscs to this mode. >> >> Therefore this patchset adds a new RED flag, TC_RED_TAILDROP. When the >> qdisc is configured with this flag, non-ECT traffic is enqueued (and >> tail-dropped when the queue size is exhausted) instead of being >> early-dropped. > ... > > Series applied, thank you. Dave, there were v3 and v4 for this patchset as well. They had a different subject, s/taildrop/nodrop/, hence the confusion I think. Should I send a delta patch with just the changes, or do you want to revert-and-reapply, or...?
From: Petr Machata <petrm@mellanox.com> Date: Mon, 16 Mar 2020 11:54:51 +0100 > Dave, there were v3 and v4 for this patchset as well. They had a > different subject, s/taildrop/nodrop/, hence the confusion I think. > Should I send a delta patch with just the changes, or do you want to > revert-and-reapply, or...? I prefer deltas, thank you.
David Miller <davem@davemloft.net> writes: > From: Petr Machata <petrm@mellanox.com> > Date: Mon, 16 Mar 2020 11:54:51 +0100 > >> Dave, there were v3 and v4 for this patchset as well. They had a >> different subject, s/taildrop/nodrop/, hence the confusion I think. >> Should I send a delta patch with just the changes, or do you want to >> revert-and-reapply, or...? > > I prefer deltas, thank you. Never mind, it's just the merge commit that contains v2, the actual patches are v4.