On Tue, Sep 15, 2026 at 09:27:51AM +0000, Ovidiu Panait wrote: > Hi Joseph, > > > > > Hi > > > > On Tue, Sep 08, 2026 at 04:43:05PM +0000, Ovidiu Panait wrote: > > > The ESVL and DOVLTC bits control S-VLAN tag processing and have > > > nothing to do with the double VLAN feature, which only provides a way > > > to process an additional inner VLAN tag. However, the driver code > > > that handles them always refers to "double VLAN", which is unrelated > > > and makes the implementation confusing. The driver does not use any > > > of the inner VLAN tag features, and the networking core does not > > > support offloads for the inner tag anyway. > > > > > > To simplify the logic and to reduce the confusion regarding S-Tag vs > > > double VLAN handling, drop the is_double logic and add a hw_svlan_en > > > flag that is set when S-Tag hardware handling is enabled. > > > > I believe I suggested to just change the "double" word to "svlan", and > > not to drop the respective logic completely. The number of S-VLAN tags > > added/removed must be still counted, otherwise any subsequent VLAN > > S-Tag removal will disable S-VLAN processing even if there are S-Tags > > left added. > > > > While working on this I realized we don't actually need to toggle the > S-VLAN bits on/off whenever a S-VLAN tag is added/removed. We can just > keep them always set as long as the NETIF_F_HW_VLAN_STAG_RX or > NETIF_F_HW_VLAN_STAG_FILTER features are advertised. > > This simplified the S-VLAN logic quite a bit, by getting rid of the counting.
and reduces the system security by permitting the packets that otherwise would be filtered out by the controller if there is no any S-VLAN tags added. So no. The counting logic here is quite appropriate(-ish). -Joseph > > Ovidiu > > > -Joseph > > > > > >
