| 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
| ||
|
Message-ID: <20140904122507.GE1867@nanopsycho.lan>
Date: Thu, 4 Sep 2014 14:25:07 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Pravin Shelar <pshelar@...ira.com>
Cc: John Fastabend <john.fastabend@...il.com>,
netdev <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>, nhorman@...driver.com,
andy@...yhouse.net, Thomas Graf <tgraf@...g.ch>,
Daniel Borkmann <dborkman@...hat.com>,
Or Gerlitz <ogerlitz@...lanox.com>,
Jesse Gross <jesse@...ira.com>, Andy Zhou <azhou@...ira.com>,
Ben Hutchings <ben@...adent.org.uk>,
Stephen Hemminger <stephen@...workplumber.org>,
jeffrey.t.kirsher@...el.com, vyasevic@...hat.com,
Cong Wang <xiyou.wangcong@...il.com>,
john.r.fastabend@...el.com, Eric Dumazet <edumazet@...gle.com>,
jhs@...atatu.com, sfeldma@...ulusnetworks.com,
f.fainelli@...il.com, roopa@...ulusnetworks.com,
John Linville <linville@...driver.com>,
"dev@...nvswitch.org" <dev@...nvswitch.org>, jasowang@...hat.com,
ebiederm@...ssion.com, Nicolas Dichtel <nicolas.dichtel@...nd.com>,
ryazanov.s.a@...il.com, buytenh@...tstofly.org,
aviadr@...lanox.com, nbd@...nwrt.org, alexei.starovoitov@...il.com,
Neil.Jerram@...aswitch.com, Rony Efraim <ronye@...lanox.com>
Subject: Re: [patch net-next 01/13] openvswitch: split flow structures into
ovs specific and generic ones
Wed, Sep 03, 2014 at 08:42:18PM CEST, pshelar@...ira.com wrote:
>On Wed, Sep 3, 2014 at 8:20 AM, John Fastabend <john.fastabend@...il.com> wrote:
>> On 09/03/2014 02:24 AM, Jiri Pirko wrote:
>>>
>>> After this, flow related structures can be used in other code.
>>>
>>> Signed-off-by: Jiri Pirko <jiri@...nulli.us>
>>> ---
>>
>>
>> Hi Jiri,
>>
>> As I indicated before I'm looking into integrating this with some
>> hardware here. Progress is a bit slow but starting to look at it.The
>> i40e/ixgbe driver being one open source example with very limited
>> support for tables, flow matches, etc. And then a closed source driver
>> with much more flexibility. What I don't have is a middle of the road
>> switch to work with something better then a host nic but not as
>> flexible as a TOR.
>>
>> Couple questions my assumption here is I can extend the flow_key
>> as needed to support additional match criteria my hardware has.
>> I scanned the ./net/openvswitch source and I didn't catch any
>> place that would break but might need to take a closer look.
>> Similarly the actions set will need to be extended. For example
>> if I want to use this with i40e a OVS_ACTION_ATTR_QUEUE could
>> be used to steer packets to the queue. With this in mind we
>> will want a follow up patch to rename OVS_ACTION_ATTR_* to
>> FLOW_ACTION_ATTR_*
>>
>
>struct sw_flow_key is internal structure of OVS, it is designed to
>have better flow-table performance. By adding hw specific fields in
>sw_flow_key, it increase flow-key size and that has negative impact on
>OVS software switching performance. Therefore it is better not to
>share this internal structure with driver interface.
Ok. I will split this leaving the sw_flow_key into ovs and introducing
new one. Thanks.
>
>Thanks.
>
>> Also I have some filters that can match on offset/length/mask
>> tuples. As far as I can tell this is going to have to be yet
>> another interface? Or would it be worth the effort to define
>> the flow key more generically. My initial guess is I'll just
>> write a separate interface. I think this is what Jamal referred
>> to as another "classifier".
>>
>> Thanks,
>> John
>>
>> [...]
>>
>>
>>> +
>>> +struct sw_flow_key_ipv4_tunnel {
>>> + __be64 tun_id;
>>> + __be32 ipv4_src;
>>> + __be32 ipv4_dst;
>>> + __be16 tun_flags;
>>> + u8 ipv4_tos;
>>> + u8 ipv4_ttl;
>>> +};
>>> +
>>> +struct sw_flow_key {
>>> + struct sw_flow_key_ipv4_tunnel tun_key; /* Encapsulating tunnel
>>> key. */
>>> + struct {
>>> + u32 priority; /* Packet QoS priority. */
>>> + u32 skb_mark; /* SKB mark. */
>>> + u16 in_port; /* Input switch port (or
>>> DP_MAX_PORTS). */
>>> + } __packed phy; /* Safe when right after 'tun_key'. */
>>> + struct {
>>> + u8 src[ETH_ALEN]; /* Ethernet source address. */
>>> + u8 dst[ETH_ALEN]; /* Ethernet destination address.
>>> */
>>> + __be16 tci; /* 0 if no VLAN, VLAN_TAG_PRESENT
>>> set otherwise. */
>>> + __be16 type; /* Ethernet frame type. */
>>> + } eth;
>>> + struct {
>>> + u8 proto; /* IP protocol or lower 8 bits of
>>> ARP opcode. */
>>> + u8 tos; /* IP ToS. */
>>> + u8 ttl; /* IP TTL/hop limit. */
>>> + u8 frag; /* One of OVS_FRAG_TYPE_*. */
>>> + } ip;
>>> + struct {
>>> + __be16 src; /* TCP/UDP/SCTP source port. */
>>> + __be16 dst; /* TCP/UDP/SCTP destination port.
>>> */
>>> + __be16 flags; /* TCP flags. */
>>> + } tp;
>>> + union {
>>> + struct {
>>> + struct {
>>> + __be32 src; /* IP source address. */
>>> + __be32 dst; /* IP destination address.
>>> */
>>> + } addr;
>>> + struct {
>>> + u8 sha[ETH_ALEN]; /* ARP source
>>> hardware address. */
>>> + u8 tha[ETH_ALEN]; /* ARP target
>>> hardware address. */
>>> + } arp;
>>> + } ipv4;
>>> + struct {
>>> + struct {
>>> + struct in6_addr src; /* IPv6 source
>>> address. */
>>> + struct in6_addr dst; /* IPv6
>>> destination address. */
>>> + } addr;
>>> + __be32 label; /* IPv6 flow
>>> label. */
>>> + struct {
>>> + struct in6_addr target; /* ND target
>>> address. */
>>> + u8 sll[ETH_ALEN]; /* ND source link
>>> layer address. */
>>> + u8 tll[ETH_ALEN]; /* ND target link
>>> layer address. */
>>> + } nd;
>>> + } ipv6;
>>> + };
>>> +} __aligned(BITS_PER_LONG/8); /* Ensure that we can do comparisons as
>>> longs. */
>>> +
>>> +struct sw_flow_key_range {
>>> + unsigned short int start;
>>> + unsigned short int end;
>>> +};
>>> +
>>> +struct sw_flow_mask {
>>> + struct sw_flow_key_range range;
>>> + struct sw_flow_key key;
>>> +};
>>> +
>>> +struct sw_flow_action {
>>> +};
>>> +
>>> +struct sw_flow_actions {
>>> + unsigned count;
>>> + struct sw_flow_action actions[0];
>>> +};
>>> +
>>> +struct sw_flow {
>>> + struct sw_flow_key key;
>>> + struct sw_flow_key unmasked_key;
>>> + struct sw_flow_mask *mask;
>>> + struct sw_flow_actions *actions;
>>> +};
>>> +
>>
>>
>>
>> --
>> John Fastabend Intel Corporation
--
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
Powered by blists - more mailing lists