Re: About structure sk_buff

[Grant Grundler]

On Mon, Jun 6, 2016 at 3:10 AM, Corcodel Marian 
wrote:

>
>
> On 06.06.2016 12:59, Corcodel Marian wrote:
>
>> Hi
>> Why sk_buff  have memory allocated on hardware drivers on majority nic
>> drivers?
>>
>
This seems like an appropriate question for netdev mailing list:
 http://vger.kernel.org/vger-lists.html#netdev

(Tip: explain in more detail what you think is wrong with "rx mode" and
someone should be polite enough to point out why it works. Offhand, I don't
quite understand what you are trying to point out.)

cheers,
grant

 This is wrong on rx mode look like:
>>
>> struct sk_buff *skb;
>> struct device *d = >pci_dev->dev;
>>
>> data = rtl8169_align(data);
>> dma_sync_single_for_cpu(d, addr, pkt_size, DMA_FROM_DEVICE);
>> prefetch(data);
>> skb = netdev_alloc_skb_ip_align(tp->dev, pkt_size);
>> if (skb)
>> memcpy(skb->data, data, pkt_size);
>> dma_sync_single_for_device(d, addr, pkt_size, DMA_FROM_DEVICE);
>>
>> sk_buff is allocated on place tx mode
>> and on start_xmit  no need to keep sk_buff on hardware structure because
>> any info is extracted from
>>  next level of driver.
>>
>>
> --
> Visit my project
> https://sourceforge.net/projects/network-card-driver/?source=navbar
>
>

Re: [Stretch] Status for architecture qualification

[John David Anglin]

On 2016-06-05 8:56 AM, Steven Chamberlain wrote:

John Paul Adrian Glaubitz wrote:

>I have invested lots of time and effort to get sparc64 into a usable state in 
Debian.
>We are close to 11.000 installed packages. Missing packages include Firefox,
>Thunderbird/Icedove, golang and LibreOffice to name the most important ones.

Is there some way to define 'core'[0] packages as blockers for testing
migration, and arch release qualification;  but other packages not?

Many of these ports would be useful if just a base system was released,
and preferably having stable/security updates for that part (otherwise
it is difficult for users to try it, developers to work on it, or DSA to
support buildds for it;  all of which are limitations on ports' further
growth).
I might mention that many kernel and tool chain bugs have been resolved 
on hppa since
we joined ports.  Total source package count  is now close to 11100, 
although this fluctuates.
Using this measure we are at the same level as alpha, ppc64 and 
sparc64.  SMP systems

are stable and run reliably as buildd machines.

Even if we increased our relative package count, we don't have the 
manpower to re-qualify
as a release architecture.  However, I like Steve's suggestion. Helge 
effectively defined a set
of core packages for hppa when he set up a new jessie-based install disk 
a few months ago.
This is currently available at .  I tend to think 
this should be done within

the context of Debian ports.

Dave

--
John David Anglin  dave.ang...@bell.net

Re: About structure sk_buff

[Corcodel Marian]

On 06.06.2016 12:59, Corcodel Marian wrote:

Hi
Why sk_buff  have memory allocated on hardware drivers on majority nic 
drivers?

 This is wrong on rx mode look like:

struct sk_buff *skb;
struct device *d = >pci_dev->dev;

data = rtl8169_align(data);
dma_sync_single_for_cpu(d, addr, pkt_size, DMA_FROM_DEVICE);
prefetch(data);
skb = netdev_alloc_skb_ip_align(tp->dev, pkt_size);
if (skb)
memcpy(skb->data, data, pkt_size);
dma_sync_single_for_device(d, addr, pkt_size, DMA_FROM_DEVICE);

sk_buff is allocated on place tx mode
and on start_xmit  no need to keep sk_buff on hardware structure 
because any info is extracted from

 next level of driver.



--
Visit my project 
https://sourceforge.net/projects/network-card-driver/?source=navbar