[EMAIL PROTECTED] wrote: >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of David S. Miller >> Sent: Tuesday, May 02, 2006 11:48 PM >> To: [EMAIL PROTECTED] >> Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org >> Subject: Re: VJ Channel API - driver level (PATCH) >> >> >> I don't think we should be defining driver APIs when we haven't even >> figured out how the core of it would even work yet. >> >> A key part of this is the netfilter bits, that will require >> non-trivial flow identification, a hash will simply not be enough, >> and it will not be allowed to not support the netfilter bits properly >> since everyone will have netfilter enabled in one way or another. > > Hi Dave, > > Do you have suggestions on potential hardware > assists/offloads for netfilter? > > I suppose some of it can be worthwhile, although in general > may be too complex to implement - especially above 1 Gig. > > I'd expect high end NIC ASICs to implement rx steering based > upon some sort of hash (for load balancing), as well as > explicit "1:1" steering between a sw channel and a hw > channel. Both options for channel configuration are present > in the driver interface. > If netfilter assists can be done in hardware, I agree the > driver interface will need to add support for these - > otherwise, netfilter processing will stay above the driver. > >
Even if the hardware cannot fully implement netfilter rules there is still value in having an interface that documents exactly how much filtering a given piece of hardware can do. There is no point in having the kernel repeat packet classifications that have already been done by the NIC. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
