From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <54AF73AD.4000008@lab.ntt.co.jp> Date: Fri, 09 Jan 2015 15:22:37 +0900 From: Toshiaki Makita MIME-Version: 1.0 References: <1420780600-11313-1-git-send-email-makita.toshiaki@lab.ntt.co.jp> <1138400428.6686751.1420782286490.JavaMail.zimbra@redhat.com> In-Reply-To: <1138400428.6686751.1420782286490.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Bridge] [PATCH v2 net-next] bridge: Add ability to enable TSO List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pankaj Gupta Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org, "David S . Miller" On 2015/01/09 14:44, Pankaj Gupta wrote: > >> >> Currently a bridge device turns off TSO feature if no bridge ports >> support it. We can always enable it, since packets can be segmented on >> ports by software as well as on the bridge device. >> This will reduce the number of packets processed in the bridge. >> >> Signed-off-by: Toshiaki Makita >> --- >> v2: Use an existing helper function. >> >> net/bridge/br_if.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c >> index ed307db..81e49fb 100644 >> --- a/net/bridge/br_if.c >> +++ b/net/bridge/br_if.c >> @@ -424,6 +424,7 @@ netdev_features_t br_features_recompute(struct net_bridge >> *br, >> features = netdev_increment_features(features, >> p->dev->features, mask); >> } >> + features = netdev_add_tso_features(features, mask); > > Just a doubt. Are we inducing latency if source has traffic at very low rate. > I mean by default do we need it? Is your concern tcp_tso_should_defer() in tcp_write_xmit()? If so, since TSO packet is created by GSO even without this patch, this should not increase latency there. This patch just delays the point of software segmentation from the bridge device to its port. Thanks, Toshiaki Makita From mboxrd@z Thu Jan 1 00:00:00 1970 From: Toshiaki Makita Subject: Re: [PATCH v2 net-next] bridge: Add ability to enable TSO Date: Fri, 09 Jan 2015 15:22:37 +0900 Message-ID: <54AF73AD.4000008@lab.ntt.co.jp> References: <1420780600-11313-1-git-send-email-makita.toshiaki@lab.ntt.co.jp> <1138400428.6686751.1420782286490.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org, "David S . Miller" To: Pankaj Gupta Return-path: In-Reply-To: <1138400428.6686751.1420782286490.JavaMail.zimbra@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: bridge-bounces@lists.linux-foundation.org Errors-To: bridge-bounces@lists.linux-foundation.org List-Id: netdev.vger.kernel.org On 2015/01/09 14:44, Pankaj Gupta wrote: > >> >> Currently a bridge device turns off TSO feature if no bridge ports >> support it. We can always enable it, since packets can be segmented on >> ports by software as well as on the bridge device. >> This will reduce the number of packets processed in the bridge. >> >> Signed-off-by: Toshiaki Makita >> --- >> v2: Use an existing helper function. >> >> net/bridge/br_if.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c >> index ed307db..81e49fb 100644 >> --- a/net/bridge/br_if.c >> +++ b/net/bridge/br_if.c >> @@ -424,6 +424,7 @@ netdev_features_t br_features_recompute(struct net_bridge >> *br, >> features = netdev_increment_features(features, >> p->dev->features, mask); >> } >> + features = netdev_add_tso_features(features, mask); > > Just a doubt. Are we inducing latency if source has traffic at very low rate. > I mean by default do we need it? Is your concern tcp_tso_should_defer() in tcp_write_xmit()? If so, since TSO packet is created by GSO even without this patch, this should not increase latency there. This patch just delays the point of software segmentation from the bridge device to its port. Thanks, Toshiaki Makita