From: Alex Aizman <alex@neterion.com>
To: Caitlin Bestler <caitlinb@broadcom.com>
Cc: "David S. Miller" <davem@davemloft.net>,
johnpol@2ka.mipt.ru, Leonid.Grossman@neterion.com,
shemminger@osdl.org, netdev@vger.kernel.org
Subject: Re: VJ Channel API - driver level (PATCH)
Date: Thu, 04 May 2006 15:49:11 -0700 [thread overview]
Message-ID: <445A84E7.1060906@neterion.com> (raw)
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F149E8D5@NT-SJCA-0751.brcm.ad.broadcom.com>
So, what are the requirements? The hardware already parses L2, L3, L4 headers,
and for the future generation we could add to the set of already supported
steering/filtering criteria. Having some discussion on the essential vs.
optional requirements seems like the right thing at this point.
On one hand, this describes what's available:
http://www.spinics.net/lists/netdev/msg04001.html
OTOH, and this is just my opinion - it'd be unrealistic to expect a general
purpose NIC to offload the entire netfilter. On the third hand, one could
think of IPsec and/or NAT, and what happens then with the hardware-supported
filtering. And so on.
There's also a question of relative importance specifically for the Data
Center environment.
Anyway, discussion would help.
Caitlin Bestler wrote:
> David S. Miller wrote:
>> From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
>> Date: Wed, 3 May 2006 22:07:40 +0400
>>
>>> On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler
>> (caitlinb@broadcom.com) wrote:
>>>>> 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.
>>> Please do not suppose that vj channel must rely on underlaying
>>> hardware.
>> I am not. I am just saying that it is futile to build
>> hardware that cannot handle netfilter at least to some
>> extent, because this will result in HW net channels being
>> disabled for %99 of real users which makes the hardware just a waste.
>
> Or netfilters being disabled, which would be just as bad or worse.
> The kernel and hardware need to co-operate so that users are not
> asked to make artificial choices between performance and security.
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
next prev parent reply other threads:[~2006-05-04 22:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-03 20:40 VJ Channel API - driver level (PATCH) Caitlin Bestler
2006-05-04 22:49 ` Alex Aizman [this message]
2006-05-04 23:04 ` David S. Miller
2006-05-05 9:36 ` Evgeniy Polyakov
2006-05-06 0:35 ` David S. Miller
2006-05-06 8:42 ` Evgeniy Polyakov
2006-05-06 8:57 ` Evgeniy Polyakov
-- strict thread matches above, loose matches on Subject: below --
2006-05-03 18:12 Caitlin Bestler
2006-05-03 18:49 ` Stephen Hemminger
2006-05-03 17:52 Caitlin Bestler
2006-05-03 15:56 Caitlin Bestler
2006-05-03 18:07 ` Evgeniy Polyakov
2006-05-03 18:45 ` YOSHIFUJI Hideaki / 吉藤英明
2006-05-03 20:35 ` David S. Miller
2006-05-03 13:56 Leonid Grossman
2006-05-03 20:23 ` David S. Miller
2006-05-02 22:53 Alex Aizman
2006-05-02 23:00 ` Stephen Hemminger
2006-05-03 6:47 ` David S. Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=445A84E7.1060906@neterion.com \
--to=alex@neterion.com \
--cc=Leonid.Grossman@neterion.com \
--cc=caitlinb@broadcom.com \
--cc=davem@davemloft.net \
--cc=johnpol@2ka.mipt.ru \
--cc=netdev@vger.kernel.org \
--cc=shemminger@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.