svn commit: r208766 - stable/8/sys/netinet

[Ermal Luçi]

On Fri, Jun 4, 2010 at 11:11 AM, Robert N. M. Watson
<rwatson at freebsd.org> wrote:
>
> On 3 Jun 2010, at 14:09, Ermal Luçi wrote:
>
>> Would it make sense to remove even passing the interface name up and
>> actually send the
>> interface index?
>>
>> That is what we are doing at pfSense and it works quite ok.
>
> I see one important argument for doing this:
>
> - Looking up an interface by number instead of by name has a number of advantages.
> - User programs that already reason about network interfaces by ifindex don't have to take an indirection.
>
> However, it has two important downsides:
>
> - It changes an existing API that a moderate number of applications depend on.
> - Applications that reason about ifnet names now have to take an indirection, which might well mean monitoring routing sockets for interface renames/additions/removals, additional sysctls, etc.
>
> As such, I'm not sure the benefits of replacing the current behavior with the proposed new behavior is worth the cost. An alternative approach might be to add a socket option to set the disposition of the divert socket, defaulting to current behavior but optionally switching to a different interpretation of the sockaddr passed in (i.e., use the ifindex instead when the option is set). Could you say a bit more about why you found this change advantageous in your environment, and whether the socket option approach would be problematic there?

Well the main motivation about it was the limitation on interface name
length that can be stored in sin_zero.

Furthermore speed processing is faster since the interface name does
not have to be reconstructed when diverting a packet.
The patch is here http://tinyurl.com/3a9h5gs

Interface event are not an issue for pfSense architecture since it
controls all the underlying data and i think most of the divert
applications do not care much about interface events apart renaming.
Keeping both options sounds reasonable too.

-- 
Ermal