From owner-svn-src-stable@FreeBSD.ORG Fri Jun 4 19:33:43 2010 Return-Path: Delivered-To: svn-src-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 850CE1065670; Fri, 4 Jun 2010 19:33:43 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5078FC19; Fri, 4 Jun 2010 19:33:42 +0000 (UTC) Received: by mail-wy0-f182.google.com with SMTP id 28so1504829wyf.13 for ; Fri, 04 Jun 2010 12:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=p1wItY9D4mx7cECRvJlc0lFzXngaJvn3+m2dNv5DZuE=; b=xY6JhnRwn2pyFWVFP1LyWKFuLCYGw+ieHG+DQ5CLCUgdEc4H9V4MwE38YeGuynry4S bEb8EpJrJn0VUKgB+UInQ/NXC6AE5y5RY7EzP4DcvsMOxV9UuHabJle1fa/adZVAACyD /OC5ysBeWDTlOCzF33ZyVv2+Lak28oDGgpOYE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=rox//qEQ6Y3F2KBHEM8B+mhVtWKuX3FFXEBvQB4jijW5/G8kWUQVNO4DT1VVG7dIBI cHMPDxrmCSm7jS42pR/8p/vhnJW+S8wuPh2chfNWVrjBnPXbAhG7aPZRbbl0tP/EGxBw YyrkQ9IROQsga026+JIy6s607VuuTl0ejQGUA= Received: by 10.216.86.195 with SMTP id w45mr2611949wee.47.1275680021712; Fri, 04 Jun 2010 12:33:41 -0700 (PDT) MIME-Version: 1.0 Sender: ermal.luci@gmail.com Received: by 10.216.8.68 with HTTP; Fri, 4 Jun 2010 12:33:21 -0700 (PDT) In-Reply-To: <0925CEED-A973-4820-A8DA-E5EDD44CCBDF@freebsd.org> References: <201006030855.o538tjke024438@svn.freebsd.org> <0925CEED-A973-4820-A8DA-E5EDD44CCBDF@freebsd.org> From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Date: Fri, 4 Jun 2010 20:33:21 +0100 X-Google-Sender-Auth: pmb5GVZRbyzwRHBdbKy6HxWCSRU Message-ID: To: "Robert N. M. Watson" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 19:33:43 -0000 On Fri, Jun 4, 2010 at 11:11 AM, Robert N. M. Watson 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