* Alexey Suslikov <alexey.susli...@gmail.com> [2014-04-21 13:56]: > Henning Brauer <lists-openbsdtech <at> bsws.de> writes: > > > I must admit I am getting tired of all these "good proposals/ideas". > > don't you think we've gone thru this before? > > Look, I haven't called them good or bad. > > > what you propose would require a custom vlan_output function which > > does nothing but setting the flag and then calls ether_output. > > what exactly is won with that? except making things less obvious? > > preparing for the highly likely case that something but a vlan > > interface (as in, IFT_L2VLAN) needs to add a L2VLAN ethernet header? > > (I understand you want code - not theoretical speculations). > > I assume, there is an input and output of a stack. > > And lot of (possible) encapsulation subsystems in the middle: vlan, > vlan-in-vlan, ipsec, you name it.
VLAN IS NOT AN ENCAPSULATION. > And if I understood your cksum plan right, being in the middle, given > packet doesn't know its destiny, but different subsystems may assign > tags so on the output packet may assemble itself right (by calling > necessary methods) where's cksum in this game??? if you're referring to "same model, emulate hw support": it is pointless here, since the point where we could set the flag is the very same point where we actually add the header! > Given a number of subsystems, delayed processing (promise pattern > variation, actually) is way to go, imo, because stack will have > homogeneous approach for entire packet assembly logic. you cannot delay this reasonably, it IS far down the road, basically right before sending the frame out. > In terms of above pattern, right: vlan_output will only set a flag > and call ether_output - this is what you already did with cksums. no, not even remotely. sigh. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
