On Mon, Nov 28, 2005 at 02:07:03AM +0100, Patrick McHardy wrote:
>
> Thanks, this looks great. I've changed it to only call the hooks
Glad you liked it :)
> before tunnel mode transforms and added a missing dst_output call
> for the final packet.
This shouldn't be necessary if you apply it on t
Herbert Xu wrote:
On Tue, Nov 22, 2005 at 09:31:39PM +1100, herbert wrote:
Unfortunately it looks like gcc 3.3.5 at least is too dumb to optimise
it away. I think we'll need a better strategy.
OK, the idea is still the same: Move the loop from dst_output into
xfrm4_output/xfrm6_output since
On Sun, 2005-11-27 at 20:58 +0100, Mateusz Berezecki wrote:
> Hello List!
>
> Having only net_device pointer is it possible to retrieve associated pci_dev
> pointer basing on this information only?
what do you need it for?
(and.. what if the nic isn't a pci one?)
-
To unsubscribe from this list
Hello List!
Having only net_device pointer is it possible to retrieve associated pci_dev
pointer basing on this information only?
kind regards,
Mateusz Berezecki
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
Michael Frank wrote:
On Sunday 27 November 2005 19:45, Patrick McHardy wrote:
I don't see how that would affect the maximum. The
question remains, why do you want to increase the
maximum?
The cause of this patch was 2.6.11 which had 10s maximum
Then just keep the maximum we have now and I'l
On Sunday 27 November 2005 19:45, Patrick McHardy wrote:
> Michael Frank wrote:
> > On Sunday 27 November 2005 02:23, you wrote:
> >>Michael Frank wrote:
> >>>To clarify the practical delay of this implementation
> >>>N_CARRIER_POLL * 0.1s + a few 100 to few 1000 us
> >>>, 0.3s - 10 times as fast
Michael Frank wrote:
On Sunday 27 November 2005 02:23, you wrote:
Michael Frank wrote:
To clarify the practical delay of this implementation
N_CARRIER_POLL * 0.1s + a few 100 to few 1000 us
, 0.3s - 10 times as fast as current implementation ;)
I understand that, but my sis900 for example
On Sun, 2005-11-27 at 19:06 +0100, Mateusz Berezecki wrote:
> Hello List,
>
> My question is about DMA transfers from network device. I suspect
> these transfers require allocating physically contiguous memory
> blocks. What is the proper way to allocate such contiguous memory for
> DMA purposes
Hello List,
My question is about DMA transfers from network device. I suspect
these transfers require allocating physically contiguous memory
blocks. What is the proper way to allocate such contiguous memory for
DMA purposes inside the kernel? Also what is the proper and
architecture independent
On Sunday 27 November 2005 01:17, Patrick McHardy wrote:
> Michael Frank wrote:
> > Current Netpoll init does not trust carrier detected
> > right upon bringing the NIC up and waits for a delay
> > before allowing boot to continue.
> >
> > The delay varied with the kernel version:
> > 10 seconds
On Sunday 27 November 2005 02:23, you wrote:
> Michael Frank wrote:
> >>>The adjusted timeout mechanism polls the carrier every
> >>>100ms and polls for a good carrier for N_CARRIER_POLL
> >>>(3) _consecutive_ cycles or 10s maximum.
> >>
> >>Why do you increase the maximum again?
> >
> > In the _cu
11 matches
Mail list logo
