[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZOPZKBdZPuEe5uKLb3sw92q3Qko4RS-90uVAQK=+pFXVAfSA@mail.gmail.com>
Date: Tue, 11 Mar 2014 08:42:17 +0200
From: Or Gerlitz <or.gerlitz@...il.com>
To: Shahed Shaikh <shahed.shaikh@...gic.com>,
Joseph Gasparakis <joseph.gasparakis@...el.com>,
John Fastabend <john.r.fastabend@...el.com>
Cc: David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Dept-HSG Linux NIC Dev <Dept-HSGLinuxNICDev@...gic.com>
Subject: Re: [PATCH net-next 1/5] vxlan: Make VXLAN default UDP port number
available for others
On Tue, Mar 11, 2014 at 7:41 AM, Shahed Shaikh <shahed.shaikh@...gic.com> wrote:
>> -----Original Message-----
>> From: Or Gerlitz [mailto:or.gerlitz@...il.com]
>> Sent: Tuesday, March 11, 2014 1:28 AM
>> To: Shahed Shaikh
>> Cc: David Miller; netdev; Dept-HSG Linux NIC Dev
>> Subject: Re: [PATCH net-next 1/5] vxlan: Make VXLAN default UDP port
>> number available for others
>>
>> On Mon, Mar 10, 2014 at 6:48 PM, Shahed Shaikh
>> <shahed.shaikh@...gic.com> wrote:
>> > From: Shahed Shaikh <shahed.shaikh@...gic.com>
>> >
>> > Although vxlan module has capability to notify udp ports to other
>> > interested net devices using .ndo_add_rx_vxlan_port and
>> > .ndo_del_rx_vxlan_port, there could be some devices which support
>> > vxlan offload but not interested in updating udp port numbers.
>> > This may be because some hardware do not support programming multiple
>> > udp ports and their drivers may decide to program only default udp
>> > port into adapter. So that adapter, at least, can do offloading for
>> > default udp port number.
>>
>> Indeed, but the default port number can be unused while another port is
>> used. The ndo will be invoked only behalf of an actual instancing of udp port
>> for listener socket (== destination port you want the hw to indentify), what's
>> wrong with support this ndo also for devices that supported limited (say
>> one) such port?
>
>
> If driver implements .ndo for udp port and user creates multiple vxlan device with different
> udp ports, it may end up programming the udp port which may not go through the adapter
> and no offload will happen. OTOH, if drive does not implement .ndo and if user is aware that driver
> is capable of offloading for default port, he can at least crate vxlan device on top of qlcnic interface
> with default udp port. So, there is no chance for other udp port numbers to replace default udp port and disturb offloading.
I see your point, but doesn't this suggests we need to somehow enhance
the current framework to
let drivers know which vxlan traffic is expected to be received over
them according to the current routing rules?
I understand this is a bit tricky because vxlan and routing are l3
constructs while drivers deal with l2, John/Joseph -
what's your thinking here?
> Like Stephen suggested, exporting udp port variable of vxlan driver will be more suitable approach.
--
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