lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 11 May 2022 22:57:46 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        Michael Walle <michael@...le.cc>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        Po Liu <po.liu@....com>
Subject: Re: [PATCH net-next 2/2] net: enetc: count the tc-taprio window drops

On Wed, May 11, 2022 at 03:27:40PM -0700, Jakub Kicinski wrote:
> On Tue, 10 May 2022 19:36:15 +0300 Vladimir Oltean wrote:
> > From: Po Liu <Po.Liu@....com>
> > 
> > The enetc scheduler for IEEE 802.1Qbv has 2 options (depending on
> > PTGCR[TG_DROP_DISABLE]) when we attempt to send an oversized packet
> > which will never fit in its allotted time slot for its traffic class:
> > either block the entire port due to head-of-line blocking, or drop the
> > packet and set a bit in the writeback format of the transmit buffer
> > descriptor, allowing other packets to be sent.
> > 
> > We obviously choose the second option in the driver, but we do not
> > detect the drop condition, so from the perspective of the network stack,
> > the packet is sent and no error counter is incremented.
> > 
> > This change checks the writeback of the TX BD when tc-taprio is enabled,
> > and increments a specific ethtool statistics counter and a generic
> > "tx_dropped" counter in ndo_get_stats64.
> 
> Is there no MIB attribute in the standard for such drops?
> 
> The semantics seem petty implementation-independent can we put it into
> some structured ethtool stats instead?

My copy of IEEE 802.1Q-2018 talks about the following MIB table entries
in clause 17.2.22 Structure of the IEEE8021-ST-MIB:

ieee8021STMaxSDU subtree
  ieee8021STMaxSDUTable
  ieee8021STTrafficClass
  ieee8021STMaxSDU
  ieee8021TransmissionOverrun

ieee8021STParameters
  ieee8021STParametersTable
  ieee8021STGateEnabled
  ieee8021STAdminGateStates
  ieee8021STOperGateStates
  ieee8021STAdminControlListLength
  ieee8021STOperControlListLength
  ieee8021STAdminControlList
  ieee8021STOperControlList
  ieee8021STAdminCycleTimeNumerator
  ieee8021STAdminCycleTimeDenominator
  ieee8021STOperCycleTimeNumerator
  ieee8021STOperCycleTimeDenominator
  ieee8021STAdminCycleTimeExtension
  ieee8021STOperCycleTimeExtension
  ieee8021STAdminBaseTime
  ieee8021STOperBaseTime
  ieee8021STConfigChange
  ieee8021STConfigChangeTime
  ieee8021STTickGranularity
  ieee8021STCurrentTime
  ieee802STConfigPending
  ieee8021STSupportedListMax

The only entry that is a counter in the Scheduled Traffic MIB is TransmissionOverrun,
but that isn't what this is. Instead, this would be a TransmissionOverrunAvoidedByDropping,
for which there appears to be no standardization.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ