netdev - Re: [patch net-next] tc: introduce OpenFlow classifier

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20150330121854.GG2045@nanopsycho.orion>
Date:	Mon, 30 Mar 2015 14:18:54 +0200
From:	Jiri Pirko <jiri@...nulli.us>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, tgraf@...g.ch,
	jesse@...ira.com
Subject: Re: [patch net-next] tc: introduce OpenFlow classifier

Mon, Mar 30, 2015 at 01:10:24PM CEST, jhs@...atatu.com wrote:
>On 03/30/15 02:26, Jiri Pirko wrote:
>>Mon, Mar 30, 2015 at 02:39:31AM CEST, jhs@...atatu.com wrote:
>
>>>Could you have got rid of "type" above given we always have
>>>a "proto" field in tc that is checked at the core?
>>
>>Sure it is possible. But I try to stick with the names used in OpenFlof
>>documentation.
>>
>
>Ok, thats fine. Safer to stick with the spec.
>
>>>Was there something else that was intended to go into that tp union?
>>
>>Following fields are missing:
>>
>>OXM_OF_SCTP_SRC
>>OXM_OF_SCTP_DST
>>OXM_OF_ICMPV4_TYPE
>>OXM_OF_ICMPV4_CODE
>>
>
>It just looked strange to have a union with only one member.

Oh, will remove the union for now as it can be easily extended later.

>
>>>General comments:
>>>so what happens if someone adds a new field? It sounds to me like
>>>given it is tied to datapath match it will never be backward compatible
>>>(i.e think old tc, new kernel vs new tc, old kernel)
>>
>>
>>Well if kernel does not understand the new field, it will simply ignore
>>it.
>>
>
>More like user expectation may be different. I suppose they could query
>the kernel and find that their field was not set.

I believe that is the usual way thing are done using Netlink API.

>BTW, another micro optimization:
>You could pre-compute the user passed key/mask result per field and
>in the fast path use that instead of doing f->match.key & f->match.mask

Yes, I plan to address this as well for v2. Thanks!

>
>cheers,
>jamal
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html