Date: Fri, 4 Jun 2010 20:33:21 +0100 From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org> To: "Robert N. M. Watson" <rwatson@freebsd.org> Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-8@freebsd.org Subject: Re: svn commit: r208766 - stable/8/sys/netinet Message-ID: <AANLkTin_ysJUCgec_-RnpSpt5Vz2mV_6RhFEtaNHWP9m@mail.gmail.com> In-Reply-To: <0925CEED-A973-4820-A8DA-E5EDD44CCBDF@freebsd.org> References: <201006030855.o538tjke024438@svn.freebsd.org> <AANLkTimEyii8eF05vgQRuSh5eQVwBceIcxwgFeUSu80b@mail.gmail.com> <0925CEED-A973-4820-A8DA-E5EDD44CCBDF@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 4, 2010 at 11:11 AM, Robert N. M. Watson <rwatson@freebsd.org> wrote: > > On 3 Jun 2010, at 14:09, Ermal Lu=E7i 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 ad= vantages. > - User programs that already reason about network interfaces by ifindex d= on't have to take an indirection. > > However, it has two important downsides: > > - It changes an existing API that a moderate number of applications depen= d on. > - Applications that reason about ifnet names now have to take an indirect= ion, 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, def= aulting to current behavior but optionally switching to a different interpr= etation of the sockaddr passed in (i.e., use the ifindex instead when the o= ption is set). Could you say a bit more about why you found this change adv= antageous 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. --=20 Ermal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTin_ysJUCgec_-RnpSpt5Vz2mV_6RhFEtaNHWP9m>