[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1374546371.4990.113.camel@edumazet-glaptop>
Date: Mon, 22 Jul 2013 19:26:11 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Cong Wang <amwang@...hat.com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>
Subject: Re: [Patch net-next 3/7] inetpeer: use generic union inet_addr
On Tue, 2013-07-23 at 10:05 +0800, Cong Wang wrote:
> On Mon, 2013-07-22 at 08:18 -0700, Eric Dumazet wrote:
> > On Mon, 2013-07-22 at 15:05 +0800, Cong Wang wrote:
> > > From: Cong Wang <amwang@...hat.com>
> > >
> > > struct inetpeer_addr is pretty similar to generic union inet_addr,
> > > therefore can be safely converted to it.
> >
> > Its 'safe' but adds 50% increase for struct tcp_metrics_block
> >
> > I fail to see this mentioned in the changelog.
>
> I asked you in RFC, but you don't give me any response, this is the
> reason. :)
>
I mentioned an increase in size of the structures, you replied :
"rearrange the fields of struct inet_peer in case of cacheline miss?"
which was a complete different matter, I had other more urgent work I
guess.
> > I guess its no big deal, but why do you think this code used hand coded
> > functions instead of generic ?
> >
> >
> >
>
> I don't understand what you are asking here, seems totally unrelated
> with the point you raised above, therefore I am completely confused...
You are sending a patch with possible performance impact, and you only
says "its safe", without any real study. It might have an impact, who
knows.
I said "its no big deal", so consider this as an informative message.
--
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