Re: bpf_mtap_softint

2017-01-22 Thread Ryota Ozaki
_softint.diff > >> >> Did I understand correctly that you will add the defered mtap to all >> drivers for now, and after the driver has been fixed it will return to >> old bpf_mtap? > > Yes. > >> So if we ask nxr for users of the defered tap and find none, >>

Re: bpf_mtap_softint

2017-01-18 Thread Ryota Ozaki
r the driver has been fixed it will return to > old bpf_mtap? Yes. > So if we ask nxr for users of the defered tap and find none, > we know that the task is done? Yes, we can know it by searching bpf_mtap_softint. ozaki-r

Re: bpf_mtap_softint

2017-01-18 Thread Martin Husemann
On Wed, Jan 18, 2017 at 04:48:32PM +0900, Ryota Ozaki wrote: > Note that it of course consumes more CPU time for softint > and more memory for m_dup. That said, I think that this is > a suitable workaround for now until someone makes them > softint-based. Could you provide some TODO like document

bpf_mtap_softint

2017-01-17 Thread Ryota Ozaki
defer only bpf_mtap to a softint handler. This is a patch: http://www.netbsd.org/~ozaki-r/bpf_mtap_softint.diff We need to only add bpf_mtap_softint_init to the driver initializations and replace bpf_mtap with bpf_mtap_softint. I tested it with wm(4) and it works for me. If someone can test the patch,