> -----Original Message----- > From: Eric Dumazet [mailto:eric.dumazet@xxxxxxxxx] > Sent: Wednesday, October 15, 2014 5:16 PM > To: Pan Jiafei-B37022 > Cc: David Miller; jkosina@xxxxxxx; netdev@xxxxxxxxxxxxxxx; Li Yang-Leo-R58472; > linux-doc@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] net: use hardware buffer pool to allocate skb > > On Wed, 2014-10-15 at 05:34 +0000, Jiafei.Pan@xxxxxxxxxxxxx wrote: > > > Yes, for this matter, in order to do this we should modify the Ethernet > > drivers. For example, driver A want to driver B, C, D.. to support driver > > A's Hardware block access functions, so we have to modify driver B, C, D... > > It will be so complex for this matter. > > > > But by using my patch, I just modify a Ethernet device (I don't care > > Which driver it is used) flag in driver A in order to implement this > > Ethernet device using hardware block access functions provided by > > Driver A. > > We care a lot of all the bugs added by your patches. You have little > idea of how many of them were added. We do not want to spend days of > work explaining everything or fixing all the details for you. > > Carefully read net/core/skbuff.c, net/core/dev.c, GRO layer, you'll see > how many spots you missed. > > You cannot control how skbs are cooked before reaching your driver > ndo_start_xmit(). You are not going to add hooks in UDP , TCP, or other > drivers RX path. This would be absolutely insane. > > Trying to control how skb are cooked in RX path is absolutely something > drivers do, using page frags that are read-only by all the stack. > > Fix your driver to use existing infra, your suggestion is not going to > be accepted. > I think my patch can connect some hardware buffer block with the third party net card drivers. this should be a general requirement in order to get a better performance. Yes, maybe some defect in my patch, but any comments and suggestions for this target is welcome and thanks. ��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
