On Mon, Jun 27, 2022 at 03:58:52PM +0300, Vitaliy Makkoveev wrote: > We can't predict netlock state when pipex(4) related (*if_qstart)() > handlers called. This means we can't use netlock within pppac_qstart() > and pppx_if_qstart() handlers. But actually we can't avoid netlock only > when we call (*if_output)() in pipex(4) PPPOE output path. > > Introduce `pipexoutq' mbuf(9) queue, and put PPPOE related mbufs within. > Do (*if_output)() calls within netisr handler with netlock held. > > The netlock assertion is still kept within pppac_qstart(), > pppx_if_qstart() and underlay code because some per session data relies > on netlock. These assertions will be removed with following diffs. > > I also want to use mbuf(9) queue for pppoe(4) input path and remove > existing serialization hack provided by kernel lock.
OK bluhm@ > #endif > +#ifdef PIPEX > + if (n & (1 << NETISR_PIPEX)) > + pipexintr(); > +#endif > + > t |= n; > } The empty line looks useless. > @@ -45,6 +45,7 @@ > #define NETISR_PFSYNC 5 /* for pfsync "immediate" tx */ > #define NETISR_ARP 18 /* same as AF_LINK */ > #define NETISR_IPV6 24 /* same as AF_INET6 */ > +#define NETISR_PIPEX 27 /* for pipex processing */ > #define NETISR_PPP 28 /* for PPP processing */ > #define NETISR_BRIDGE 29 /* for bridge processing */ > #define NETISR_SWITCH 31 /* for switch dataplane */ Tab and space are inconsistent. I prefer space after #define, then it does not jump when you look at the diff. Mixing looks ugly.
